We have a data acquisition system communicating with 20 Watlow F4 and Watlow F4T’s. We are using the Modbus subroutine as Master with a 3 wire serial drop to the slaves. We always leave the communication “open” but after a time of not communicating with an f4T, it wont establish com. The only way i have found is to restart the strategy,
I was reading about the commands and saw that you can query the com handle if it is open (and it will be), but the other side has closed and it is in a “half open” state. Could this be our problem?
How can i query if the other side is ready? or is there a command to reset the com handle?
When we monitor the RS485 duplex line (for weeks with an oscilloscope) the problem doesn’t happen. Needs solution, I cant restart the strategy every time We want to establish com. any ideas?
This typically wouldn’t be the case with a serial connection, however the PAC with a serial module functions like a TCP to serial bridge. I’ve never have left a serial connection open without using it so have never experienced the issue you are having, but I do wonder if the internal TCP server is closing the connection leaving it half open.
I’m puzzled as to why adding an oscilloscope prevents the issue from happening. Maybe some noise is getting added to the line that is getting picked up as characters keeping the connection alive.
Are you able to modify the strategy to close the comm handle when you are not going to be using it for a while?
Another thing you may want to check and change is in the modbus subroutine, open the block called ‘Open’, it may look like this:
if (GetNumCharsWaiting(chCommHandle) < 0) then
nStatus = OpenOutgoingCommunication(chCommHandle);
else
nStatus = 0;
endif
I recommend changing it to this, as it is more robust:
if (GetNumCharsWaiting(chCommHandle) < 0 or not IsCommunicationOpen(chCommHandle)) then
nStatus = OpenOutgoingCommunication(chCommHandle);
else
ClearCommunicationReceiveBuffer(chCommHandle);
nStatus = 0;
endif
Okay I will do that. I also added a counter to my loop that looks for open chambers to communicate with. If it cycles all the way through and none are open, it closes the com handle until one is opened. I will update this post again if it still happens. Thanks for your help Philip, Opto Awesome to the rescue.
well, still happening.
Now I am having problems with Reading reg as floats. I can read “as Int” but the “read reg as floats” is not working. I have gone through all the settings, but since I can read Int registers I figure is the subroutine, maybe corrupt?
I will download again…
Since it is serial, make sure you have a short delay between each modbus request. The delay needs to be 3.5 characters long, 9600 baud you will want 4ms between receiving a response and sending out the next request.
I’ve not heard of (part of) a subroutine getting corrupted… Not saying it can’t happen, just saying in about 40 years of Opto, I’ve not seen it or directly heard of it.
I’m guessing it used to work and then just suddenly does not?
Are you able to connect to the Watlow’s with another Modbus tool?
I’d use Node-RED since I know it well and its already on the EPIC, but you might have experience with another bit of software to poll the float registers for a period and make sure nothing is happening outside of PAC Control.
I’d also consider using a USB to serial adapter to fully step outside of the EPIC serial module as well, but you could test it via the module as it mounts in Linux and Node-RED can see it that way.
Are you getting an error modbus status or are you getting nonsensical values? If the latter, then yes, could be byte order or starting address being wrong.
