MaRine Posted July 1, 2008 Report Posted July 1, 2008 I am using LV7.1. I customize a type def enum control and use it as a queue element. There are several steps in this enum control such as initial, scan label, print, write database and so forth. I think it is a common use in LV. Now I have a problem with 'print step'. I am using Zebra printer(model ZM400). It will print out two same labels some time. At first I suspect that I send the print command twice.So I increase the time delay to 500ms every step Because there is time string at label( format as 20080630143856). If I sent two commands, the time will be defferent after several steps. I have try print label using other application. There is no such problem. So I think the Printer is OK. I aslo search help from this forum and this address: I have disconnect enum constant from type def control but there is no use. Is there anybody who can help me? Thank you in advance. Quote
Ton Plomp Posted July 1, 2008 Report Posted July 1, 2008 QUOTE (MaRine @ Jun 30 2008, 08:48 AM) I am using LV7.1. I customize a type def enum control and use it as a queue element. There are several steps in this enum control such as initial, scan label, print, write database and so forth.I think it is a common use in LV. Now I have a problem with 'print step'. I am using Zebra printer(model ZM400). It will print out two same labels some time. At first I suspect that I send the print command twice.So I increase the time delay to 500ms every step Because there is time string at label( format as 20080630143856). If I sent two commands, the time will be defferent after several steps. I have try print label using other application. There is no such problem. So I think the Printer is OK. I aslo search help from this forum and this address: http://forums.lavag.org/Typedef-enum-CONST...ml&hl=queue I have disconnect enum constant from type def control but there is no use. Is there anybody who can help me? Thank you in advance. What is exactly the problem? The (always) changing date is that part of the enum string? If so, don't do this! I think you should try to print a label from a simple VI, and then place it into your state machine. Ton Quote
MaRine Posted July 1, 2008 Author Report Posted July 1, 2008 QUOTE (tcplomp @ Jun 30 2008, 05:07 PM) What is exactly the problem?The (always) changing date is that part of the enum string? If so, don't do this! I think you should try to print a label from a simple VI, and then place it into your state machine. Ton Sorry for my English. Maybe I have not descriped the problem easy to understand. The problem seems like some steps of enum run twice but not the printer problem. I just want to ensure if the 'print' step run twice by trying to change time string at label. Quote
Phillip Brooks Posted July 1, 2008 Report Posted July 1, 2008 I'm guessing that your mechanical action for the Print button is different than your other buttons and that you are using a "Value Change" event to trigger your print action. Until will generate two value change events; one for the down and one for the up... Example (7.0) Download File:post-949-1214824868.vi Quote
Humenik Posted July 10, 2008 Report Posted July 10, 2008 QUOTE (MaRine @ Jun 30 2008, 05:47 AM) Sorry for my English. Maybe I have not descriped the problem easy to understand. The problem seems like some steps of enum run twice but not the printer problem. I just want to ensure if the 'print' step run twice by trying to change time string at label. QUOTE (MaRine @ Jun 30 2008, 05:47 AM) Sorry for my English. Maybe I have not descriped the problem easy to understand. The problem seems like some steps of enum run twice but not the printer problem. I just want to ensure if the 'print' step run twice by trying to change time string at label. Sorry for the repeats ... I tried to upload a code snippet with a reply and this web GUI went into permanent UPLOAD mode, would not complete. Without the snippet, I wnated to say that if you are using a state machine that is queue-driven, and an element of your queue is your enum, be careful that you test for queue lack-of-timeout before engaging a case of interest. Seems in lv7.1 I have noticed that my default enum value can be presented to my case selector in the event of a timeout. Some interacting between the while loop time delay and the queue timeout. Anyhow, testing to see if the queue hasn't timed out each cycle of the while loop solves the problem.. Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.