G’day
I am having trouble changing the baud rate on Ser0 on a PAC-S2 controller. I was under the impression from all the documentation that all 4 ports on the PAC-S2 could be either RS232 or RS485 and any combination of other comms settings I choose. For some reason, despite trying all the usual methods the port seems stuck on 19200bps.
For my application I was intending to use Ser0 and Ser1 on the S2 both as RS485 @38400bps for some modbus channels.
Using code I have already developed and tested successfully on my other PAC-R1 systems (some use SCM-485 modules, some use the PAC-R1 dedicated port ser0 with a RS485/RS232 converter) I have made what I believe are the necessary changes to the Communications Handle definition in the strategy. For this I have tried both methods appropriate for onboard controller serial ports:
Format 1: “ser:0,38400,n,8,1” and
Format 2: “ser:port=0,baud=38400,parity=n,data=8,stop=1” etc
The appropriate RS485 termination and bias settings were configured and PPP switched off in PAC Manager as usual. The RS485 side of things seems to be working fine also.
Despite doing this, when I start the chart and it spits out data, it is always set at 19200bps which I have been monitoring on Putty, RealTerm and a Modbus Slave emulator I am using. There is no doubt it is 19200. The runtime “inspect” window of the comms handle shows it is holding the config string as listed above.
As a sanity check I tried swapping over to using the other native S2 serial ports. All 3 other ports ser1, ser2, ser3 work as expected and accept the 38400bps setting and dish out data at 38400.
Has anyone else had this issue? Am I missing something in the documentation that says that there is something special about PAC-S2 ser0 or that it can only be 19200? Yes, I could always just push on and use ser2 and ser3 for the RS485 modbus channels but I feel there is something minor I haven’t caught here and someone out there can enlighten me.
Thanks in advance.
Sean
This does not sound right at all.
It also seems you are doing everything right.
Its going to take some time for me to set up all the hardware here to test this and I am assisting Benson in a really big webinar this morning so wont be able to get to it for a while.
If you need some help asap, please drop a request into our support team.
Thanks Ben. I think I resolved it. This is a weird one.
Today I went through the same steps to reproduce the problem, starting with a working system using serial2 at 38400bps. I swapped the working chart over to using serial0 by changing the single character port number in the Comms Handle config string. This time I am able to configure serial0 to 38400bps no problem. What was different about today? Power cycle? I think so but I’m not 100% sure why. Anyway, I managed to recreate the problem with the following sequence of events:
I have another chart running a piece of survey equipment in this strategy which I am not using on this development project that also uses ser0 at 19200,8N,1. The use of ser0 on this survey chart is simply a legacy thing from migrating this strategy over from using a PAC-R1 previously and I haven’t got around to re-configuring it for the S2 serial ports. When I first went to test my new Modbus chart (the one causing the issue using ser0 on the S2 in the first place) I realised this would have been a conflict with both charts wanting some ser0 action and removed the “Start Chart” command for the old survey chart from the Power Up chart. As expected, commenting out this Start Chart command required a new download/store to flash for the S2, yet for some reason the ser0 port remains stuck at the 19200 settings, despite the Modbus chart explicitly defining ser0 with the following:
SetCommunicationHandleValue(“ser:0,38400,n,8,1”, PTX_MODBUS_Upper_Manifolds_Transducers);
and also despite the fact that the survey chart never starts and never gets to run its equivalent SetCommunicationHandleValue(“ser:0,19200,n,8,1”… command. I re-created this situation today by first putting the survey chart back into action and forcing the conflict. The port operated at 19200. I then commented it out again, re-downloaded, then it was still stuck at 19200.
On cycling the power to the S2. The same strategy starts up (with the Start Chart on the survey chart commented out) and the ser0 port behaves as expected for the Modbus chart at 38400bps.
Conclusion: The only thing I can think of is that the hardware side of ser0 gets stuck on 19200 only after it has had a previous conflict during this power up (2 charts fighting to set it up at two different baud rates), remains unresponsive to subsequent configs and does not reset across strategy downloads, but only recovers once the S2 has been power cycled. I must’ve inadvertently done a download earlier in the day where the conflict was still in the strategy and the port was frozen from then on.
I guess it was a nice waste of several hours going around in circles when all I should have done is turned it off and on again…
Thanks for your time
Sean
