I understand that part but how do I write it so it talks to multiple slaves with different registers?
I understand that part but how do I write it so it talks to multiple slaves with different registers?
If I wanted to talk to two slaves with function code 3 do I have to have 2 function 3 subroutines and copy paste function 3 general setup and read in the main chart to call out the subroutine for slave number 2? With the same comm handle.
Yes, you would call the subroutine for each slave. You can use the general setup as an example for your own chart.
Something like this:
ntModbusSettings[0] = 0;//Protocol - 0 = Serial RTU, 1 = Serial ASCII, 2 = Modbus/TCP
ntModbusSettings[2] = 1000;//Timeout in ms
ntModbusSettings[3] = 0;//Word Order - 0 = Lower register least significant, 1 = Lower register most significant
nModbusStatus = 0;
//Read register 1 through 10 into ntSlave01Values for Slave 1
ntModbusSettings[1] = 1; //Set slave unit ID
O22Modbus03ReadHoldingRegistersAsInt(chModbusMaster, ntModbusSettings, 0,
1, ntSlave01Values, 10, nModbusStatus);
DelayMsec(5); //Need 3.5 char delay between response and new request 4.2ms at 9600bps
//Read register 101 through 120 into into ntSlave02Values for Slave 2
ntModbusSettings[1] = 2; //Set slave unit ID
O22Modbus03ReadHoldingRegistersAsInt(chModbusMaster, ntModbusSettings, 0,
101, ntSlave02Values, 20, nModbusStatus);
The above logic would be run in a looping chart with an appropriate delay.
cool and one last thing. in pac control the error box is filled with -47 errors. the chart keeps trying to open comms but its already open so it throws in this error and in the chart it accounts for it. if “nstatus” is 0 OR -47 it passes but my error box in pac control is filled. anyway to get rid of this?
Which chart is opening the comm handle? You don’t need to open the comm handle in your chart, as the modbus subroutines will open it if it is not open. If you are continuously getting this data you shouldn’t close the comm handle either.
This is what calls the subroutine. i have it set to 1
also the error tells me this is where its getting its error from because its already open. and to your point, i dont think its closing the session but trying to open it every time it goes through the chart because it says “open session failed because its already opened” its trying to open the session but its already open so it throws an error. “SetCommunicationHandleValue(“ser:0,9600,E,8,1”, chModbusMaster);”
If you’re using the kit as is, then I am not sure - the subroutines have this at the top of them:
if (GetNumCharsWaiting(chCommHandle) < 0) then
nStatus = OpenOutgoingCommunication(chCommHandle);
else
nStatus = 0;
endif
which calls the GetNumCharsWaiting which will be 0 or higher if the comm handle is open.
Can you open the O22Modbus03ReadHoldingRegistersAsInt subroutine and modify the “Open” script block to be the following:
if (GetNumCharsWaiting(chCommHandle) < 0 or not IsCommunicationOpen(chCommHandle)) then
nStatus = OpenOutgoingCommunication(chCommHandle);
else
nStatus = 0;
endif
I have it like that in my personal modbus subroutines and maybe I added that because of what you are seeing at some point - I don’t remember.
thank you! i’ll let you know how it goes on monday
Hello Opto Team,
Would you please help me with an issue I am having with the Modbus Master kit? The keywords in this thread matched what I was looking for and here I am.
While debugging, I am getting the nStatus value in the O22Modbus03ReadHoldingRegistersAsInt subroutine as -87. What does nStatus = -87 mean?
(The communication handle is set as ser:0,19200,n,8,1 – for Modbus/RTU. I am unable to see any data in the PAC control’s return tables, yet. I could see data from the Modbus device (VFD) on my PC using ModbusPoll app.)
Please help.
Thank you very much.
-87 is “Open Error” (You can look these up in PAC Control, Help, Error Lookup).
What kind of Opto device are you using? EPIC? If EPIC, USB to serial, or CSERI module? The comm handle is different depending on the kind of device you are using, and I suspect that is where your issue is.
Hello Philip! Thank you so much for your response. I am using groov EPIC PR2 with the CSERI module on slot 0. The comm. handle that I am using is “ser:0,19200,n,8,1”. Is this the right one?
This post here will help you a great deal.
About 1/2 down I make a post with 4 screen shots, that should get you going.
Thank you, Beno and Philip! You are awesome! As Philip mentioned, the issue was in the comm. handle. I had to change the line in the ‘General Setup’ optoscript block to this to make it work:
SetCommunicationHandleValue(“@VFD_301:baud=19200,parity=n,data=8,stop=1”, chModbusMaster);
I am seeing non-zero data come through now. I am yet to figure out what I am seeing, doesn’t look right at the moment. But I am seeing another issue now.
Sometimes I get all zeros and sometimes I get non-zero data in the return table.
When I get all zeros, I checked the nStatus/n03AsFloatStatus bit and it was toggling between 0 and 2. I checked the error description for value “2” , it is “Checksum or CRC Mismatch”.
When I get non-zero data, the nStatus bit stays at 0.
Is there something that I am doing that is causing Checksum or CRC Mismatch? Please help.
Thanks a lot again.
Make sure you have a at least a 2ms delay (1920 characters/sec and 3.5 character modbus spec delay) between modbus requests to allow the VFD RS-485 transceivers to switch from transmit to receive.
I have set a 20ms delay in the blue ‘Read Delay’ block. Is that where you wanted me to check? Or, is it inside the O22Modbus03ReadHoldingRegistersAsFloat subroutine in the Modbus master kit?
Please advise. Thank you.
The communication is working for me now and the data that I am receiving makes sense now. Some things I noticed earlier about the nStatus value toggling between 0 and 2 and also later between 0 and 4, incase somebody else has similar issues.
I do not know the exact reason, but this toggling happened whenever I entered a register address that was not a holding register address. For example, my data was at register address 9505 (decimal) and if I entered 9504, I saw the toggling happen and it left me with all zeros as the return data. If I entered a valid address, then there is no toggling and data looks good.
Thank you again, Beno and Philip for your help!
Hello Ben,
Would you have any advice on how to set up a communication handle for a second serial device on groov EPIC’s GRC-CSERI module?
Currently, I using the following code to talk to the first device, on CSERI module’s channel 0:
SetCommunicationHandleValue(“@VFD_301:baud=19200,parity=n,data=8,stop=1”, chModbusMaster);
Do I need a different comm. handle for a second serial device?
Please advise. Thank you.
Each serial module supports 4 serial devices.
You will need to configure all 4 if you want to use each.
Just follow your own posts in this tread.
Thank you, Ben! Will try a different comm. handle for each device.
