Reading data over serial port - Need help with code optimization

[SMJ_AX]

I'm reading data from a device (data output: 10 data point/sec) over a serial port. The code uses basic event struchture for user interface.

I'm facing trouble with the code during testing and the issue are not consistent/repeatable eg: code freezing due to event not recognized, graphical/numeric indicators on front panel not updating real-time.

We didnt face these issues before until we created an installer and installed the exe on a new system.

I'm not sure if the code is eating up too much of memory or if there's any inherent code related issue for the cause.

Any suggestions to improve overall performance of the code are greatly appreiciated.

Thanks.

Sri

PS: I have attached the vi for reference.

[Albert.Geven]

Don't put that many communication vi's (visa serial line) in the event case.

Use the event case only for events and handle the details in a separate while as you have done in the lower while.

Although your program is perfectly readable try to use wires instead of local variables. These are real time eaters.

You probably have people who click twice when nothing happens and lock up the frontpanel.

Check in the event case if locking is enabled for all events.

[SMJ_AX]

Mr. Geven,

Thanks for the response. The device has some intelligence built into it and responds to commands and hence the serial vi's in some event cases for GUI based device interaction for data collection.

All the events make sure that the front panel is locked-up since the objective is to have systematic test process to collect the data. Is it hurting in this case?

The application was fine until I added the second while loop in the timeout event case, I think I can make it work if I can synchronize the loop execution (as data dependency is not a solution in this case). I'm thinking of using occurrences as its simple and I don't have any data flow too. Any suggestions?

I have also changed the priority of exe from normal to time critical, disabled anti-alias feature for graphs & increased the timeout for event struchture to 500ms, hopefully this would help me a bit.

Looking forward to your thoughts on the above points.

Thanks,

Sri

[crossrulz]

You also hit one of my pet peeves.  You used property nodes to get/set the values of controls/indicators.  If you have to do this, use the local variable.  The local is EXTREMELY faster than the property node (I'm talking in the order of thousands of times faster).

[Albert.Geven]

Hi

When you move the actual code out of the event case, and move all the commands to be executed into a queue just like you did to the lower loop, you don't have to be affraid that the queue is corrupted or that a command is executed in a wrong order.

The event structure meant to handle events and to handle the task of execution over to other handlers.

I am afraid that locking after an event in this case blocks the system. So start with removing all locks. If it still is wrong check in which state problems occur.

And indeed locals are faster than property nodes but wires are even faster and a declaration page as you have in the left part of your diagram gives me the idea that you programmed in Pascal long time ago. Just like me 20 years ago already.

[SMJ_AX]

Geven/Crossrulz,

The code actually started out to be a simple event struchture and exploded into the humongous code you see now :)......i wish i had the clear picture, now i feel a state machine approach would have been more appropriate.

Also, what do you mean by using wires instead of local variables? It might sound silly, but its been a while I used Labview and still am new to the shortned version of names?

The declaration page is just for self reference & also thought its cool so that someone else who uses this code (or even for myself after 5-6 months) can easily understand it.

Thanks for the suggestions, I haven't tested the code with the device yet, but the code seems faster than before after setting the values using locals than property nodes (the reason for it to have proper data flow through error in/out wires), guess i need to use flat sequences instead now.

Will post the updates soon....

Sri

PS: I was expecting the worse(to modify the whole code). Anything else in the code that needs a second look?