From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

A possible problem with parallel operation?

Hello everyone,

         I am working on a labview program that uses parallel execution, and I am running into a possible problem. Please bear with me, as sometimes it is difficult to explain things happening in Labview in text alone. 🙂 This application reads data from a server that we have in one of our labs via an ActiveX component. This server is known as a TIU server. The server contains various data including part numbers, serial numbers etc. It sends this data out in three different signals. A sequence count, an ASCII high, and an ASCII low. The sequence counter sends data in the following manner. When the sequence count is 0 and both ASCII high and low are NULL, then a new part number sequence is about to begin. When the count sequence changes to "1", then the next two string charaters listed under ASCII high and ASCII low represent a number that is a "Function ID". There are several of these, and each function ID contains different information either a part number, a serial number, etc. Once this is read, and it is determined that you are looking at the correct Function ID, the next Count shows how many charaters are to follow, and then you read each set of two ASCII characters and concatenate them together until you build the entire ASCII sequence as one variable and the sequence is complete.

       There are several equipment cards attached to this TIU server, and each card is free wheeling it's data out. As soon as power is applied, it will continue to send out all of its function ID's sequentially (Function ID 0-9) in order, in a circular fashion at a 1 Hz. rate. A really strange system to be sure, but it is a limitation that I have to deal with. So now that I have laid a bit of the background on this, here is the problem. Occasionally, (maybe one out of 20 trys), the data seems to get slightly corrupted. For example, in the enclosed code, I ran it 40 times, reading the same part number each time. In theory, it should always be the same result. But it is not. I am wondering if there is an issue with running the "READ TIU SERVER.vi" in PreAllocated clone reentrant execution mode? Perhaps on occasion, one of the instances does not fully close, before another instance begins, and a few bits get flipped around? I suppose it is possible that occasionally the TIU server is actually putting out erroneous data (and I am actually reading everything perfectly), but it is a fairly mature system, and I have not gone down that path yet. I have included the .vi that I am using to read the server data "test.vi", and the "Read TIU Server.vi" that is set to Preallocated clone reentrant execution. In this example, the "test.vi" is only a single instance, but in the actual program, I am running 20-30 of these, as Preallocated clone reentrant execution as well. As there are 20-30 cards on each TIU server to get information from. I am hoping that this makes sense, and that I have laid it out in a logical fashion. Sort of hard to explain in text sometimes. Thanks for the help....

Download All
0 Kudos
Message 1 of 5
(2,420 Views)

What is the function of the many "elapsed time" express VIs? Since they are not hooked up to anything,  they don't really do anything useful. Were you thinking of a wait funtion instead? Lots of the code seems a bit odd, e.g. the presence of a shift register where the shifted value is never even used.

 

Sorry, I am not familiar with the instrument, so I cannot comment on the rest of the code.

0 Kudos
Message 2 of 5
(2,395 Views)

Hi ,

      Thanks for taking a look. You caught me on the shift register, I had not gotten around to cleaning up a few things. However the "elapsed time" functions acutally are there on purpose. Unfortunately, it takes a VERY long time to get one of those part numbers, as only two ASCII characters are moved accross the bus at a 1 Hz. rate. I orginally had all wait statements, but I discovered that when you stop a while loop, it will continue until the wait timer has expired. With 20+ of these functions in parallel, it was taking upwards of 30 seconds for the program to finally end. From what I was reading on the forums of others that had that problem, a "elapsed time" function can be broken through, while a standard "wait" statement cannot. Now when I press the "STOP" button, the program ends almost immediately.

     This is not a standard piece of equipment that I am using, but I think the explanation is of how it works is fairly accurate. Would you have a guess as to why every so often the data gets corrupted? Other than the bus itself is actually putting wrong data out there? I suppose I should check that as well, but due to the slow rate of the bus, and the tools that we have, I will have to sit and watch it for a long time... Thanks...

 

Dan

0 Kudos
Message 3 of 5
(2,359 Views)

The elapsed time function does exactly nothing (or less!) in your code. It is used to measure time, not control it. Read the help.

0 Kudos
Message 4 of 5
(2,350 Views)

Wow.... that is highly embarassing for me. However, that might explain the strange behavior that I have been seeing. If each loop is running literally as fast as it can with no delays, then I could see how the data could get corrupted on occasion. Forgive my ignorance... Thanks...

0 Kudos
Message 5 of 5
(2,335 Views)