LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Potential bug/"Featurette": Modbus Stops when changing date time

I found out (the hard way) that when I changed the time on a PXI chassis, the deployed Modbus libraries Halted.

 

The were still active and contained data, but the timestamps were all from when I changed the time.

 

I had to stop and re-start both the Serial and TCP/IP Modbus Libraries using distribution manager before they recovered.

 

Any thoughts/Comments.

iTm - Senior Systems Engineer
uses: LABVIEW 2012 SP1 x86 on Windows 7 x64. cFP, cRIO, PXI-RT
0 Kudos
Message 1 of 8
(2,260 Views)

Hello Timmar,

 

Do you have some specific steps to reproduce this behavior? Which PXI chassis do you have or you got this behavior with different devices?

 

Regards 

0 Kudos
Message 2 of 8
(2,225 Views)

I haven't Gone out of my way to test it.

 

Step 1: @12:44pm,  Change AM to PM using the web interface on a PXI-8108.

Step 2: Wonder why Clients interface ceases to Work

Step 3: Distribution Manager: Observe All Modbus Variables last Updated @ 12:44. It is Now 15:30

Step 4: Stop and restart Modbus processes using Distribution manager.

Modbus Libraries begin updating, Last update 15:30:12 , 13, 14, 15....... (normal).

 

*Controller was not reset during this process.

iTm - Senior Systems Engineer
uses: LABVIEW 2012 SP1 x86 on Windows 7 x64. cFP, cRIO, PXI-RT
0 Kudos
Message 3 of 8
(2,216 Views)

I have used modbus but don't know much about the protocol itself. Does it use some sort of timestamping in the protocol and changing the clock while running throws it out of whack? For instance, if it thinks it went "back in time" or something of the sorts? This is a total stretch, and with my limited knowledge most likely incorrect. It seems this should be supported, as I'm assuming many people sync their PXI time to another source nightly, and modbus should transition seemlessly through this.

0 Kudos
Message 4 of 8
(2,212 Views)

We pay NI a big swag of money each year so I don't have to know about the modbus Protocol.

I write to an NPSV and the driver does the rest for me.

 

My expectation is that a clock change should be seamless, Going back in time should flag an error handling case that corrects for it.

Worst case I get a data Glitch (Which is why I did it while the system wasn't in use)

iTm - Senior Systems Engineer
uses: LABVIEW 2012 SP1 x86 on Windows 7 x64. cFP, cRIO, PXI-RT
0 Kudos
Message 5 of 8
(2,206 Views)

Ah, I haven't used modbus with NPSV. I have used these VIs in the past. I'm curious if you run into the same problem using those. It doesn't solve your problem (I agree it should be handled, and I'm by no means suggesting a solution is refactoring your code to use these VIs) but it may be something to test from a comparison standpoint. 

0 Kudos
Message 6 of 8
(2,203 Views)

This posting was mainly meant as a cursery warning to other modbus users.

 

My Workaround is to reboot the contoller after changing the time.

 

Also as a gentle prod to the NI boffins that it is a potential bug.

 

As to the VI's

The functionality is Now Fully integrated into the NPSV liabries.

iTm - Senior Systems Engineer
uses: LABVIEW 2012 SP1 x86 on Windows 7 x64. cFP, cRIO, PXI-RT
0 Kudos
Message 7 of 8
(2,200 Views)

@Timmar wrote:

This posting was mainly meant as a cursery warning to other modbus users.

 

My Workaround is to reboot the contoller after changing the time.

 

Also as a gentle prod to the NI boffins that it is a potential bug.

 

As to the VI's

The functionality is Now Fully integrated into the NPSV liabries.


Alrighty, I thought it was a complete show stopper. And that is good to know about NPSVs...although, in general, I try to avoid them.

0 Kudos
Message 8 of 8
(2,196 Views)