Printing labels (barcode, datamatrix code, ...) with LabView via Codesoft (activeX automation open ref close ...)
in [LabView]
|
From: maximint on 6 Jan 2007 06:40 Hi together, ok I found a VI (see attachment) which seems to do the job. Simple labels (without variables until now) are printed.The problem. It takes about 5 sec. until the label is done.I got it faster after removing the "Close Reference" VIs (see attachment).The problem now: for each label we print, a new refernece will be opened without closing.May be I'll have problem after label number 1009 or so?My plan:I want to open in a sub VI the application property and the document methode ONE TIME after starting up the programand write the ref and so on in global variables. The whole things should be closed one time at the end of the program.But this doesn't work. It works only one time.It seems that for each label I print, a new ref must be openend, but this takes time.Could anybody help?Many Thanks, Thomas. ActiveX1.vi: http://forums.ni.com/attachments/ni/170/222927/1/ActiveX1.vi ClipBoard-1.jpg: http://forums.ni.com/attachments/ni/170/222927/2/ClipBoard-1.jpg
From: JLS on 8 Jan 2007 14:10 Hello, You should not leave references open, especially if you'll be performing the open operation arbitrarily many times using a loop. That will "leak" and grow memory usage, which can ultimately make your program even slower. You may be able to print using a command line operation using the system exec VI, but I am not sure if this will be faster. Best Regards, JLS
From: maximint on 10 Jan 2007 13:10 Hi <a href="../view_profile?user.id=33102" target="top" class="auth_text" style="font-weight: bold;"> JLS</a>, 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 withCodesoft 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. print label.vi: http://forums.ni.com/attachments/ni/170/223449/1/print label.vi
From: rolfk on 11 Jan 2007 04:40 maximint wrote:Hi <a class="auth_text style= FONT-WEIGHT: bold" href="http://forums.ni.com/ni/view_profile?user.id=33102" target="top"> JLS</a>, 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 withCodesoft 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 TekLynx.zip: http://forums.ni.com/attachments/ni/170/223574/1/TekLynx.zip TEKLYNX Buffer.zip: http://forums.ni.com/attachments/ni/170/223574/2/TEKLYNX Buffer.zip
From: rolfk on 11 Jan 2007 05:40
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 |