02-21-2023 02:08 AM - edited 02-21-2023 02:11 AM
That clarifies a lot. The printer obviously requires also a printer driver to be installed that makes the device available as printer. The printer driver API in Windows is VERY old, dating back to Windows 3.0 times and it hasn't been changed that much yet. There are various wrappers made around it and the Report Generation Toolkit is one of them, but that was done in ActiveX and Microsoft rather would have everyone stop to use ActiveX today than tomorrow and has actually removed support to create or even recompile ActiveX components from Visual Studio for quite some time. But this Report Generation Toolkit is not meant to print a single string but rather full pages of data similar to an Excel spreadsheet or a HTML page.
Your options are limited in this case. You could access the low level Windows printer API through Call Library Nodes. That is however a very tedious and painful process and only doable if you know a lot about C level programming. More promising is likely to interface to the .Net PrintDocument class through the .Net nodes in LabVIEW. Not that it will be trivial but it is at least a path that will give you a chance to get something done without having to continuously restart LabVIEW after a crash. Fiddling with Call Library Nodes is a sure way to crash your program over and over again, even if you know what you are doing and are very proficient in C programming, so you want to avoid that as much as possible. the .Net route has its own challenges, especially the needed event callback can be a bit tricky to get right as it often feels counter intuitive, but it at least shouldn't continuously crash LabVIEW.