continuously reading modbus registers

[jmejiagusmer]

I am having a problem with my VI reading some vfd hz speeds over a modbus tcp connection via ethernet. I am having no problem pinging the device so I know that a connection is established already. As you can see in the block diagram, I am trying to read a certain register from the device continuously and display it on "hz 1" as it changes. I also would like for there to be a timestamp display every time that this hz value changes. Here are the problems that I am having:

1) the hz speed always displays properly right when I hit run, but there are times where I will change the hz speed on the device and labview will not update it at all

2) sometimes the hz speed will update instantly a few times and then stop updating

3) the timestamp string has never functioned properly and I am not sure what is wrong with it

Thank you all for any help you may be able to contribute! 

[Zwired1]

variety of issues:

The timestamp is not updating because it is only written insde the event structure "Hz 1 value change".  This event won't "fire" unless you change the value of Hz 1 by writing to the "Value (signaling)" property or change it by user typing (but it's an indicator so that doesn't apply here).  

Consider using a Queued Message handler to coordinate your multiple loops. 

   -- you can better manage your infinite password change loop

   -- you can better react to you temp controls and better display to your torus indicators.  They currently update/get polled only once and then when you click on the Read/Graph while loop stop button

   -- you can have one stop button that sends an "Exit" message to the other loops instead of stopping them with mulitple buttons.

The DAQ read issue may be because of the task clear and task create inside the outer while loop.  When you hit "stop" the Read/Graph while loop stops, which allows the task clear to run and the outer while loop to iterate (the rest of the stuff in the outer loop has long since completed because there is no data dependency) . The next iteration of the outer loop immediately tries to create the task and it may not be ready/uncommitted (?). Try moving the create task and clear task outside the outer loop, at least.

Refactoring shouldn't be too bad as you have several loops/functions already.  The QMH will just let them run independently without causing one that should run quickly to wait for one that has to run slowly.

[jmejiagusmer]

---

@Zwired1 wrote:

variety of issues:

The timestamp is not updating because it is only written insde the event structure "Hz 1 value change".  This event won't "fire" unless you change the value of Hz 1 by writing to the "Value (signaling)" property or change it by user typing (but it's an indicator so that doesn't apply here).  

Consider using a Queued Message handler to coordinate your multiple loops. 

   -- you can better manage your infinite password change loop

   -- you can better react to you temp controls and better display to your torus indicators.  They currently update/get polled only once and then when you click on the Read/Graph while loop stop button

   -- you can have one stop button that sends an "Exit" message to the other loops instead of stopping them with mulitple buttons.

The DAQ read issue may be because of the task clear and task create inside the outer while loop.  When you hit "stop" the Read/Graph while loop stops, which allows the task clear to run and the outer while loop to iterate (the rest of the stuff in the outer loop has long since completed because there is no data dependency) . The next iteration of the outer loop immediately tries to create the task and it may not be ready/uncommitted (?). Try moving the create task and clear task outside the outer loop, at least.

Refactoring shouldn't be too bad as you have several loops/functions already.  The QMH will just let them run independently without causing one that should run quickly to wait for one that has to run slowly.

---

My timestamp is not generated within the event structure. It is just outside of the event structure for that reason. If the event won't fire when the indicator value is changed by the modbus read, then how else could I go about printing out the timestamp string to "time since last change"? I would like to be able to place a timestamp and display it any time that the value is changed at the device. Thank you for the suggestion of the QMH. I don't know what it is or how it works, but I will definitely look into it if it will help out my VI. I don't have any DAQ read issues, so maybe I wasn't very clear with my original post, sorry. Thank you for your response!

[Zwired1]

Here is a way to update the timestamp based on a change of any element in the "Hz 1" indicator.  Not sure why "Hz 1" is an array if you're only showing one element on the front panel but the code below will compare the previous loop's value for Hz1 to the current value (element by element in the array) and if any are different it will update the timestamp.  Clearly I don't have the modbus VIs loaded

I said QMH.  To be honest, it's been a while since I looked at the templates and I was thinking about what I typically do ( and probably erroneously call a QMH).   You would probably want the "Producer/Consumer Design Pattern (Events)" template.  I would extend the producer functionality to control more consumers (more parallel loops) by adding additional queues so the producer could send a message  to a particular consumer as needed.

http://www.ni.com/white-paper/3023/en/

One more hint: I would not recommend using a 30000ms wait function in a while loop.  This means that you might have to wait 30 (or maybe 60) seconds for the stop button to have an effect.  It would be better to monitor an elapsed time and pass the "has it been more than 30 seconds?" result to a case structure.  If TRUE, run DAQ read and graph update, otherwise check the elapsed time again.