LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Intermittent Read Problem - Invalid Weight Data

Problem - Intermittent Read Problem (~1/15 actual reads) where invalid weight data (0) is read from a weight balance when the user presses the transfer key. It happens on the very first run in either Column, Row or Single Entry Method. It can happen anytime the Program has been stopped, new entry method selected and program started again.

 

Debug - I highlighted execution and the weight data appears to be flowing normal even when the invalid weight data appears in the Weight Value Window or written to the Spreadsheet ! I did manage to find a race condition in the Read Case where I initialize Weight Value to zero then perform the read weight code and write the data to Weight Value so I moved the initialize Weight Value to zero into the Check Event Timeout Event Case. The intermittent Read Problem still exists !

 

Attached is a zip file containing all of my Project Files, if someone could please review and let me know where there might be possible sublte issues/problems that would be great !

 

Thanks !

 

Barry

 

0 Kudos
Message 1 of 3
(2,307 Views)

Hey Barry,

 

I am currently taking a look at your project and am having a little trouble following the flow.  And I think this is going to cause some big problems regarding the efficiency of being able to debug this.  If you don't mind, I have a few suggestions:

  • I think this system would benefit from a producer/consumer architecture.  Right now the way you have this set up it will consume more CPU then necessary.  Get the event structure out of the processing loop and put it in it's own loop.  Set the timeout to -1 and just have all processing cease until a response is necessary.  Commands can be sent via a queued state machine from the UI loop (the producer) to the processing loop (the consumer).
  • You have a lot of superfulous structures in here - I am thinking primarily of the flat sequence structures that seem to be peppered about the VI.  Let the flow be controlled by the wiring when possible.
  • Try to pare down the number of property nodes and local variables you are using (for instance, the Run-Time Status is updated in almost every structure so there is no need to place a local variable inside each one - simply place this outside of the overarching structure and populate it as necessary).
  • Get rid of the Exit Labview functionality when an EXIT Program event is fired!  This was incredibly surprising when I attempted to open a file, canceled it and then proceeded to watch LV disappear.  At the very least this is not helpful to those attempting to help you and it is entirely not necessary. I would suggest removing the EXIT Program boolean and replacing it with a Panel Close? event which fires when a user hits the x in the top right hand corner of the screen - you can choose to filter this and keep the VI open and stop running it or simply close the VI when the user does this; in either case, LV remains open.
  • Consider configuring com on your serial port 1x at startup (i.e. when the program is opened) rather than every time bytes are read off of the serial port (which is what you do now).  Configuration is only necessary once - this will open the port for communication and provide a handle with which you can make reads on the port.  Since you never close the connection and yet you continue to open the connection each time you "Initialize Scale COM Port", it's not clear to me that this will not create problems. (I guess LV is smart enough to know that it is the program that currently has that connection open and utilizes this knowledge such that no error is thrown).
  • Your error handler doesn't seem to do anything except clear errors (and it also contains a superfulous case structure as if an error is indicated, of course the case will always trigger "Error"); if you are not actually handling errors, get rid of this case and use the "General Error Handler" to provide indication to the user or to clear the error.  This will get rid of the need of an error shift register.

Anyway, I think that if you address some of these issues, the problems that you are seeing may become more apparent.

 

Peace, Matt

0 Kudos
Message 2 of 3
(2,296 Views)

Hi Matt,

 

Thanks for your feedback and constructive criticism, I will look into implementing some or all of your sugestions.........

 

Barry

 

0 Kudos
Message 3 of 3
(2,275 Views)