LabVIEW
Printing labels (barcode, datamatrix code, ...) with LabView via Codesoft
@maximint wrote:
Hi JLS,
thanks for the answer. I agree with you that closing the references is the best und most stable solution. But it is really slow. I made an exe but this is also slow.
But apart from this, the VI is running well, even with a handing over of variables. I guess this is one of the first VIs in the net which combines LV with
Codesoft from Teklynx.
Thanks, Thomas.
PS: I made a wrong click on the rating of your last post. Sorry. I guess I rated it too bad.
Well, this is easily solved with an intelligent global buffer VI or as they are also often called a LabVIEw 2 style global. I use them quite often for all kinds of reasons including to avoid globals in my programs almost 100% but this is one of the cases where they are also very handy.
Basically you write a VI that has a while loop, and a case structure inside. The while loop normally only executes once. One or more uninitialized shift registers store different values that can be reused on each call to that VI. The case selector is wired to an enum (I make them always strict typedefed) on the front panel and that one is connected to the connector pane of the VI.
Make the enum have init, print, close items and in the respective case frame do the opening of the refnum in the init case and anything else you need to do once at initialization time storing the refnum to the right shift register terminal. In the close case do everything to close done the software and then close the refnum coming from the right shift register terminal itself passing a Not A Refnum to the right shift register terminal. The print case uses the refnum from the right shift register terminal too, does all that is necessary to do printing and then stores the refnum back to the right shift register terminal. You now have an intelligent manager function for your interface to the printing software.
The init case is called somewhere during initialization of your application while the close case is called somwehre when you close your application. A variant is to combine the init and print case but forst test for the refnum to be Not A Refnum (comparison palette) and in that case do the initialization first, otherwise just do the printing. The advantage with this is that the Codesoft interface is only initialized if you really need it.
There is one caveat for this if you use dynamic top level VIs to implement for instance test steps or deamon like operation. LabVIEW remembers the top level VI under whom a refnum was opened and automatically closes refnums when that top level VI goes idle (stops running). So you would need to make sure that the initialization is done in the main hierarchy that is guaranteed to run for the entire time that your interface is required.
I have included a small archive containing an API for Codesoft 7 that also supports variable query and substitution in templates. It is an older version of something I'm currently using and not very well tested as is, but the newer version is a lot more involved and complicated and not suited to be put here. I also included another archive showing a version of such an intelligent manager buffer function using that API.
Rolf Kalbermatter
@maximint wrote:
Hello Rolf,
many thanks for the detailed answer to my Codesoft Problem. I want to try your VIs.
Could you please post the missing VI "file valid path.vi"
Many Thanks, Thomas.
Well it's not a very important VI and quite simple to do yourself. Just combine the output of Not A Path and Is Empty Path nodes from the comparison palette with a NOR function and you got it. You can also download the OpenG libraries where there is that VI in the files package, but then with the OpenG postfix as that VI originally comes from me.
Rolf Kalbermatter
@maximint wrote:
Hi,
thanks for you Codesoft VI. I tried them now with success, this means, at startup of my program, I run one time the OPEN, INIT etc. and multiple times the PRINT.
But one problem still occurs:
I tried to simulate our future main VI: as described, calling one time the OPEN, INIT etc and then running a while loop where I can start your PRINT VI
by pressing a button. Here I found that the print of the label isn't realized immediately. It takes some seconds. Too long for our production. I guess that the while loop takes too much performance and the activex component doesnt get enough.
Therefore I want to wait for the event "End Printing" and tried to handle this with the attached VIs. But although the printer is ready, I cannot recognize the corresponding event.
Could you have a look, pls. Thanks.
Sorry not for the moment. I'm actually only doing the init at program startup, loading a new template whenever is required, replacing the template variables as needed and then printing it out. Most software has a serious delay from the moment starting the print command until data is actually rendered and passed to the printer driver. I'm not sure you can get sub seconds reaction with standard Windows printing at all. Anyhow for me it is not a problem at all as I print a label only after some more or less lengthy test procedure when the tests have succeeded so printing even if it takes a few seconds is fast in comparison to the rest.
Rolf Kalbermatter
does anybody else has any idea why the
and the
does not work as expected?
Thanks.
 |
ActiveX Event Callback for Codesoft.vi (28 kb) |
and the
|
end printing event call back.vi (23 kb) |
does not work as expected?
Thanks.
