LabVIEW
How to control the printer of USB interface
@Lchjxlz wrote:
Only can print paper is un-useful ? you mean base on link to create a .dll library and use labview to call library ?thanks
It's slightly more complicated than what zou says. A GDI printer driver CAN support raw passthrough. The emphasis on CAN is intentional. If it does or not and how exactly is entirely up to the printer driver developer and that is something neither you nor us can control.
The link I posted contains C code and you COULD compile that into a DLL and call that from LabVIEW with the Call Library Node. You also COULD decide to forgo the creation of that DLL and call the according API functions directly from LabVIEW with the Call Library Node but that is some serious work too and requires you to know at least as much about C programming as if you had to develop that C code in that link yourself.
I'm not sure how exactly the Windows printer spooler passes RAW data to the printer driver. But if you specific RAW is means that the Windows printer spooler does not try to interpret, alter or otherwise modify anything in the data byte stream. It takes the byte stream you pass in and hands it off to the printer driver and basically simply says "I don't know what this is, and supposedly the application handing it to me indicated that they claim to know what it is and you should be able to do something with it, so here it is, do your thing and hopefully you will be happy with it".
The problem with these passthrough methods is however that they are normally unidirectional. Especially the ExtEscape() method is documented to only support unidirectional transfer to the driver with the PASSTHROUGH escape code so it will likely not work for your problem of requesting information from the printer. However ExtEscape() also allows custom escape codes that are driver specific so your driver may use one of those (and certainly supports several custom escape requests) to do what you want. However this information is usually VERY proprietary and most printer manufacturers will rather cut their hands off than openly document them anywhere. You as a service provider for one of those manufacturers should be able to get that information for their driver, we as mere mortals will most likely just get a blank stare if we asked anyone from Huawei technical support if such escape codes do exist.
If they can't provide you with that information for whatever reason and can't give you the actual source code of a C, C++, C# or God beware, some actual LabVIEW code, you are simply unable to do what they expect you to do and you have to tell them so and explain that you can not work under these conditions on this project. It is as simple as that.
If you get access to such information but your level of knowledge is not sufficient to apply it, you would have to share it here, but first will need to get approval to do so, or hire someone who does have that knowledge and can assist you with it after they signed an according NDA. That's how things work and expecting anything else is simply planning for failure.
