Debugging old spaghetti code - Que element not Triggering

[Atamsih]

Dear Everyone. 

I encountered a bug some old code and I need to fix it because it is now hurting my productivity. The code is spagetti code and very hard to get a grasp of. I made it in 2012 but since then it has been modified a few times by other authers and I have not used it much.

Anyway: What it does is control a number of instruments using a QSM and OEM toolkits. The way it does it is that it read a text file like the one I attached, each statement that ends with ; is a name of some item in the "master loop" that does something start/stop a measurement on one of the devices. The specific problem is that Send Pressure Loop Stop does not trigger correctly, at least the corrosponding pressure measurement is not stopped and the program "hangs", I need to make sure that it fires correctly.

Any advice on how to approach this problem? Could I somehow make the code more managable or write entirely new code?

Maybe a sub point is: How does the get queue status work? I need to know if it never leaves the queue or something else is wrong.

I do not this will actually be looked over but I have to try.

[Alexander_Sobolev]

I have looked at that portion.

Are you running with auto error handling enabled? There are several places that might cause program to go wrong way in case of error. Like mistypes in text file, daqmx task errors, etc.

Technically sending stop pressure does not stop daqmx task, it stops reading from it. Will give error (buffer overwritten) on next start.

To debug, try to isolate the parts (very general advice).

Does it run/stop pressure loop from buttons?

Try to run file like right after program starts.

Send start pressure; Wait 2s; Send stop pressure;

To modify structure:

Move loops into subVIs.

Try to add one more level of hierarchy for the main commands: command + data, specific for command instead of single command

I did not like this approach with confirmation from the valve loop. It almost triples number of commands (send start, start execute, start) and a potential source of race conditions.

May be state diagram toolkit.

[Alexander_Sobolev]

PS. Queue status checks the current queue status. Does not affect elements, can read them without removing from queue.

[Atamsih]

Hey Alex

Thank you for your input. 

There is not much in the way of error handling. But it is pretty stable. The worst chrashes we've had were due to broken ram block. IRC the problem is also "immune" to spelling mistakes because it sanitizes input so if it does not mactch it disregards it. 

There reson it does not stops the daqmx task is that the user will need to see the pressures on the UI all the time. Are you suggesting that the reson it happens is that the buffer in the DAQmx is full?

The reason it has a "confirmation" loop is that the h6-t queue actually does not exist, when that queue recieves a start command then it just signals a different part of code automtically. With the Valve loop that condition would fire as soons as the Master loop read the corrosponding command of the text file.

Finally could you suggest a way to create a subVI in the file? I always struggle with creating them because I cannot decide how much needs to go in there.

Again, many thanks for you input. I will try making some files that will trigger the problem. 

[Alexander_Sobolev]

>> IRC the problem is also "immune" to spelling mistakes because it sanitizes input so if it does not mactch it disregards it. 

Hmm, when I mistyped command (Send Pressure Loop Sstop), scan from string complained and placed default act into list (Button Control.Custom event).

>> There reson it does not stops the daqmx task is that the user will need to see the pressures on the UI all the time. Are you suggesting that the reson it happens is that the buffer in the DAQmx is full?

Hmm, when pressure loop receives Stop program, it flushes queue - that removes repeat of Running. Pressure loop waits for next command, displays nothing. 

When you send Start program again, it tries to resume reading from the same task, usually this results in error with overwritten buffer. if you ignore error, it will continue reading.  This should not cause program hang.

Can not delays and confirmations be handled by main loop? Add timeout into dequeue, check if time has passed, do not freeze loop  (with wait.vi like it is done in valve loop). This makes more sense, valve loop will handle only valve commands.

>> Finally could you suggest a way to create a subVI in the file?

hmm, Select -> Edit -> Create subVI? Or new -> VI -> Ctrl+C -> Ctrl+V.

>>  I cannot decide how much needs to go in there.

I would put all equipment loops into subVIs. You will still be able to access Queues by name from subVIs.

Common problem will be how to show data in main vi. 1) SubPanel - each subvi displays acquired data on its front panel, subVI is inserted into subpanel container. 2) Producer(s) - Consumer template. 3) Pass main vi elements references into subVIs. 4) etc.

[Atamsih]

Dear Alex

Sorry for the long waiting time for a reply. I've been spending some amount of time trying to get into to the nuts and bolts of it all. 

Regarding the command spelling, you're right, I know I made something that checked for it 5 years ago but it is not in this version. That is not really a problem though as it runs a number of set rutines that have been determined to work.

Regarding get queue status, how does this function work? I've tried applying it but if I put an indicator on the elements the indicator is blank or empty. 

Regarding the SubVI's I am experimenting with it. 

Regarding the overlaying problem: I am still moving stuff out of the valve queue and debugging all the functions. Will be a while, but I will properly close this thread soon. 

Thank you so much for your help so far. 

[Atamsih]

Sorry for the long waiting time for a reply. I've been spending some amount of time trying to get into to the nuts and bolts of it all. 

Regarding the command spelling, you're right, I know I made something that checked for it 5 years ago but it is not in this version. That is not really a problem though as it runs a number of set rutines that have been determined to work.

Regarding get queue status, how does this function work? I've tried applying it but if I put an indicator on the elements the indicator is blank or empty. 

Regarding the SubVI's I am experimenting with it. 

Regarding the overlaying problem: I am still moving stuff out of the valve queue and debugging all the functions. Will be a while, but I will properly close this thread soon. 

Thank you so much for your help so far. 

[Alexander_Sobolev]

>> Regarding get queue status, how does this function work? I've tried applying it but if I put an indicator on the elements the indicator is blank or empty. 

Most probably the element gets into the queue for a short moment - The target loop is waiting for the new element and new one gets dequeued immediately. You will not catch that moment by polling once in 100 ms or what is your polling loop rate.

If you want to get the order of elements being put into queue, make the "debug" queue and add the same element as into the working queue, dequeue it in a separate subvi. 

Get status is more usefull for the cases when there are random delays in "consumer" loop and queue starts to grow.