Our full technical support staff does not monitor this forum. If you need assistance from a member of our staff, please submit your question from the Ask a Question page.


Log in or register to post/reply in the forum.

CR1000 OS27 - Modbus on COMrs232


cunningham Feb 7, 2014 02:27 PM

hi all,

i am using a CR1000 with a modbus device connected to the ComRs232 port.
I encountered a strange behaviour and can't spot any mistake on my side.
I am running this test-program:

Public result As Long
Public val(36) As Float
BeginProg
SerialOpen (COMRS232,19200,3,0,512)
Scan (1,Sec,0,0)
ModBusMaster (result,comrs232,19200,1,3,val(),6000,36,1,50,0)
NextScan
EndProg


Everything works fine if the logger has OS26 running.
If OS27 is used, the "result"-var,indicating success or failure of modbus-transaction, is never changing.
I manually set this variable via ConnectScreen to some value >0.
With Terminal emulator, i was able to monitor the transaction taking place and also the val-array gets filled with the correct values.
But despite being a "successful" transaction, the result-var stayed on the current value, while a "0" should be expected.
Once firmaware has been reverted to OS26, everything works fine.
As i use modbusTCP under OS27 quite often, i am wondering if i encountered a bug, or if there is some reason to this, which i can't see.

I was able to reproduce this with two different loggers.
Can anybody confirm this is known behaviour under OS27?

Thanks.

* Last updated by: cunningham on 2/7/2014 @ 7:28 AM *


Sam Feb 7, 2014 05:59 PM

Several customers have brought up a (now) known bug in OS 27 related to ModbusMaster().

During the move from OS 26 to OS 27 a bug was introduced where the result code does not increment on failed communication. The result code does properly reflect error codes returned by the slave. However when a master polls the slave and the slave does not respond the result code is not incremented from 0 as indicated by the help.


Campbell Scientific has available OS 27.03 that includes the fix for this as well as a few other communication related improvements. The changes between 27 and 27.03 are fairly minor. To request a copy of OS 27.03, please contact your Campbell Scientific office. We also hope to make this version available for download at http://www.campbellsci.com/downloads in the near future.


Though I can not provide a fix without an OS change (e.g. loading OS 27.03 or 26), I can offer the following advice. I think this advice applies very well to Modbus, PakBus, SDI-12 polls, etc. I think it is advisable to initialize your destination variable to a known state, typically an error state, before the poll occurs so that you can programatically tell if there was an error in populating the destination variable with new data. This can aide in
detecting faults that for one reason or another might not be reflected in the result code of the instruction. It can also help in making sure that you are not using "old" data for current processing.


Here are some code examples that might be of help

'MODBUS
Public Result,Val(5)
BeginProg
Scan (20,Sec,0,0)
Move (Val,5,NAN,1) 'populate array with NAN
ModbusMaster (Result,COM1,115200,1,1,Val,1,5,3,100,0)
If Result < 0 Then
'application layer error detected
ElseIf Result > 0 OR Val(1) = NAN Then
'link layer error detected
EndIf
NextScan
EndProg


'SDI-12
Public Val(5)
BeginProg
Scan (20,Sec,0,0)
Move (Val,5,NAN,1) 'populate array with NAN
SDI12Recorder (Val,1,0,"M!",1.0,0)
If Val(1) = NAN Then
'error detected
EndIf
NextScan
EndProg


'PakBus, GetVariable
Public Result,Val(5)
BeginProg
Scan (20,Sec,0,0)
Move (Val,5,NAN,1) 'populate array with NAN
GetVariables (Result,COM1,0,100,0000,0,"Public","ValToGet",Val,5)
If Result < 0 Then
'application layer error detected
ElseIf Result > 0 OR Val(1) = NAN Then
'link layer error detected
EndIf
NextScan
EndProg


cunningham Feb 10, 2014 09:12 AM

hello sam,
thanks for pointing this out.
As this is only a minor issue for me at the moment, i will use OS26 until release of OS28, which is absolutley ok for this system.

Just took some time to realize a bug could be the reason :)
greets!

Log in or register to post/reply in the forum.