error in typedef comparison

[LV_Pro]

Hi All,
   I've run into a strange problem. My program has three primary vi's running simultaneously, one that does OPC reads& writes,through RSLinx through ethernet, one that is reading a Eurotherm controller via MODBUS over a serial port and a user interface that displays the read data and sends any control changes back to the OPC R/W to be sent to the PLC. They all are communicating via a named queue the elements of which are  typedef clusters, one element of which is a typedef enum "destination". When I do the preview queue element I look at that value to see if the destination matches and if so, pop the element off the queue. What seems to be happening is that when the program is running occasionally it appears that the element that is popped off the queue isn't for the vi that is reading it, i.e. I will have an element that is supposed to be going to the Eurotherm being executed in the OPC vi. Is it possible for another element to be added between my "preview" and the actual "popping" of the last element? In the enclosed snapshot, the correct destination would be  "OPC communications" but at the customer's site (where I can actually run against the PLC and Eurotherm hardware) I am getting instances where my OPC communications Read Items fails, getting a "Read Items" command that was destined for the Eurotherm or User Interface.

Writing some simple vi's to randomly send data through this mechanism hasn't revealed anything. I'm trying to modify my code to use the built in LabVIEW simulated data available through OPC, but haven't gotten it running yet.

Running:   Windows XP sp2  1G Ram
                  LabVIEW 8.2.1
                  RSLinx 2.5  OEM

Thanks, as always.

Message Edited by LV_Pro on 07-05-2007 11:45 AM

[tst]

I would point to the All option as the most likely suspect. If all three VIs are running at the same time, then it is possible that you will have this:

1. A previews the queue and sees All.
2. B previews and sees All.
3. A extracts All.
4. B extracts the next element, which actually belongs to A.

Do you have a log of messages sent\popped with timestamps?

[johnsold]

Putnam,

This sounds like a place where an action engine might be better than just using the queue functions. One of the actions could be Preview/Match/Extract with the typedef value as the Match input. The action engine VI would preclude the multiple reader race condition.

Although messier, mutiple queues should also work.

Lynn

[Jarrod_S.]

Or use a single non-reentrant subVI which would have sole responsibility for reading the queues and doing the Preview/Match/Extract.

The advantage there over using an Action Engine is that the writers wouldn't be blocked by the readers or each other.

[mikeporter]

I think I agree with tst, the problem is very likely in the "all" destination. What I hear you saying is that all three destinations need to respond to this one message, but only one can delete it. So the problem is figuring out which one should do it. I think I would lose it in favor of explicitly "addressing" each destination. There are just too many opportunities for race conditions otherwise.

Alternately, you could structure the "all" command as a user event that can get fired in all three destinations simultaneously. In that case the event data could carry the command data that is now in the queue.

Mike...

[LV_Pro]

Thanks for the input folks. Going to my customer's this morning to try them out. As to the "All", the only instance that it gets sent is if any of the loops detects a reason to shutdown, where upon it "shutdown" is sent to "All", that loop quits, the first loop to receive it the starts its shutdown procedure and re-enqueues the "shutdown" command, but at the head of the queue, instead of the tail, so that it is the first queue element seen by the remaining loop. I'm feeling pretty sure that what is happening is a different "race" condition, where the queue is checked, the loop decides that it is a command for it, and in the mean time another command has been placed on the queue. One of those "gotcha" things, where, even after 14 years of LabVIEW, I was thinking serially, in two dimensions, rather than in three.

Thank you again,

[tst]

---

@LV_Pro wrote:

I'm feeling pretty sure that what is happening is a different "race" condition, where the queue is checked, the loop decides that it is a command for it, and in the mean time another command has been placed on the queue.

---

That's what I thought at first too, but I figured that the dequeue only happens if the first element does belong to the current VI, so unless there is a place which does not follow this rule or a place where you place an element at the beginning of the queue, I don't think this should happen.

[LV_Pro]

    Decided to opt for the simplest, just dequeue, check as before, and if it isn't for this loop, put it back on the queue. Don't remember why I chose to do it the way I did, have been working on this project off and on for about a year and a half (mostly off!). We (my customer and I) are trying to finish it, but there were aspects of the program that I don't remember why I chose. And this is with my leaving lots of comments, both the permanent ones (that remain in the program) and my own notes to myself, that indicate things I want to revist when the heat of creation has passed. Those I mark, in my case with my initials, so I can search the code to find them. I tend to put them in when I hit someplace where, as I'm coding, I discover stuff I want to ask the customer about, or where I'm not sure that my algorithm is really what it should be, but I'm really cranking, in the groove and don't want to do a context switch and loose the thought. But I guess it seemed obvious to me when I did the preview queue, so no comments. Then again, it might have been discoverying something in LabVIEW and looking for a reason to use it!  I'll let you all know how it works out. Glad it (the problem) cropped up while I was in the debug/integration period, can see how it might not have, which would have produced "flaky" code, with weird intermittent errors. I really strive to not do that!

Thanks again. I tell all my customers, that actually develop LabVIEW, to really use this resource, tell them that they usually will get answers in a surprisingly short time, from some of the worlds top LabVIEW experts, but am still pleased with how fast you all respond when I am on the asking rather than the answering side.

What time is it where you are tst? It is pretty early in the business day here (I work from a home office), but I seem to recall that we others guessed you lived way east of the eastern US, or way, way west, depending on which way one decided to travel!!!

Message Edited by LV_Pro on 07-06-2007 08:08 AM

Message Edited by LV_Pro on 07-06-2007 08:10 AM

[LV_Pro]

Forehead slap and a DOH! That theory (that something was added in the interim) obviously doesn't fly as it would be added at the other end of the queue, as you remind me tst!  I guess too little sleep at this end. Working on two projects, as well as a bunch of non LabVIEW stuff. Well, it appears that what is happening, based on a lttle test, is that when the preview timed out it returns a default value, which, as I was developing the OPC loop first, just happens to be with "OPC communications" as the destination. This causes the check to return a true, and the next value is popped off the queue, which isn't necessarily for OPC. Doing what I suggested, of popping, checking and re-enqueuing isn't the answer as it will mean that the other loop's stuff may keep getting put at the front of the queue if the other loops (in one of my scenarios there is a PID controller as well) happen to execute first.   I was part way there, having placed the constant in there to guarantee the output of the case, rather than the "use default", but didn't make the next logical step. Guess I didn't really think about timeouts, was thinking only in binary, data meant for this loop OR "valid" data not meant for this loop. Didn't think of "invalid" data meant for this loop!  Now I remember why I did the preview, just neglected to use the time out to confirm that what I check was valid data. Thanks tst! Gonna go get some coffee, seems the brain is a little too cotten filled this morning.

Message Edited by LV_Pro on 07-06-2007 08:38 AM

[tst]

Well, it looks like you're the one who solved it in the end, because we all failed to notice that you used a timeout for the preview node. I think I assumed either that you don't have timeouts or that your timeout is the default -1.

---

@LV_Pro wrote:

What time is it where you are tst? It is pretty early in the business day here (I work from a home office), but I seem to recall that we others guessed you lived way east of the eastern US, or way, way west, depending on which way one decided to travel!!!

---

I guess you don't follow the BreakPoint enough. 

The local time for that last post was 14:52.