It seems you have two problems now. You mentioned the communication failure at beginning, and then the pot's value has problem. Do you still see the communication failure after you reinstall everything? If you still have the modbus communication problem, please make the serial log file again.
How do you connect the pot to the driver? Do you set up in Edit Conntions or in pot's "remote source"? If you use the Edit connection, it is a one-way connection, so the pot's value should only be changed by user input. Or if you use "remote source", it is a two-way, then the pot's value can be changed by driver object.
You can also check the alarm/event database. If the pot's value is changed, there is an event saying "pot's value is changed from user input" or "from remote source". Open MAX, create an Alarm/Event Viewer to view the events. From the event, we will know how the pot's value was changed. I don't think it was changed by itself.
I never thought the pot objects changed themselves, but they are randomly assuming their maximum values, even with the remote HMI screen disconnected...
There is no other way those pots can change unless Lookout is doing it. I would have liked to know why. I mean they should not assume new values if a com fail occurs should they?
We were trying to follow some of Cal Poly's guidelines and have an HMI at the site and Lookout at the office both able to control the PLC and update the value of the pot in both locations whenever it was changed from either location.
I had tried using remote source but that really only lets the remote HMI control it. So I used local on the pot and then edit connections to tie the pot to the modbus driver.
That works in theory, but it can become a tug of war between the remote HMI and Lookout. We have since gone a different direction wrt to the pots. No more bi-directional control and only one "master" at a time, either the HMI screen or Lookout, never both.
I will be in contact with the customer today and see if comms broke down over the weekend.
Still can't see why it will work for 30 hrs or more after a re-install and then start struggling to stay in communications. Even though I am using individual writes, I would hope Lookout could handle that even though it does increase the amount of serial traffic.
ps, just to prove my point, I just modified one of the pots to use "remote source" and broke the connection for that pot from the modbus object and it now does not allow user input from Lookout, only from the PLCs register...
In other words, if I change the pot value in Lookout, it snaps back to the old value in the PLC as soon as it polls, never writing to the holding register.
There was a breakdown last night.
It appears that modbus update is staying true all the time on all objects during this type of failure.
A little background on why it appears to be this way:
We have polling done by a sequencer object. We have on delay timers set/reset by modbus update members for each modbus driver in use that will trigger an alarm if polling stops.
Well, during this failure mode, those timers are not getting started by the modbus update object. We do not get the alarm since the update members are never transitioning to the off state to start the timers.
They all stay off until a reboot/restart of the computer and then things are normal for 12 or so hours.
(30 hours with a re-install)
To really prove this, I would need to have multistates tied to the update members and or trend their activity. I will do that on my next visit.
The owner will start a diagnostic file next time we see a failure. I have also asked that he look at task mgr during a failure to see if any processes are using high amounts of processor.
A quick way to check for a frozen update member.
Get all of the objects and create a delayon timer.
SiteActive can be a simple switch
This will take the amount of sites active and compare it to the sites that are updated, if the update count matches the active site count, connect an alarm point to the timer. This is just an example, have to take the commfail points into effect. Don't have the example process with me right now.
Doesn't fix the problem, but at least operators are notified.
Thanks, that sounds very useful. I will check this out, I need my operators to be able to provide this kind of feedback to me.
It is looking like a frozen update member(s) though.
No, they should not assume new values. That's why I suggested you to take a look at the events in Citadel database, which can tell us how the value was changed.
If possible, please upload your process file to ftp://ftp.ni.com/incoming. I aslo need the serial port log file when you have it. The log file tells us what really happened on the port.
The update datamember of modbus goes TRUE when it finishes a poll. It will goes to FALSE after it starts next poll. If it stays true all the time on all objects, it means all objects stopped polling. They were doing nothing at that time.
1. The modbus objects were not triggered to poll because of logic problem, or bugs in other object, such as the sequencer you said.
2. One modbus object was polling, and went into a deadlock. It never finished the polling, so that no other objects could start to poll. If so, this is a bug in modbus. And I need the log file to troubleshoot it.
I think the delayon timer should start when update goes to true, and reset when it goes to false, because true means it finishes an update, false means it starts a new poll. But it seems you connect it by a opposite way.
We were hoping to get Lookout working on this system using modbus modes 5 and 6 since the PLCs in question are self contained pump control stations with 6 to 8 pumps.
The code for the pump station PLCs was written with the pump controllers being the highest priority. We could have then come in later, attached Lookout to I/O and been done with it.
Well, Lookout is clearly struggling with multiple write/read cycles involved with mode 5 and 6 communications. Unless something major changes on Lookout, it seems that Lookout will never be stable in our system as written.
We have decided to abandon mode 5 and 6 addressing and re-write the PLC code so that all I/O is in contiguous blocks, and use mode modbus 15 instead. As I said we were resisting this since it seemed to us that Lookout should be able to function under single coil/register read/write conditions and stay stable but I don't think that is forthcoming.
We thought that since Lookout had single coil/register read/write functionality included that it would work. We did not care how much radio traffic it involved as long as Lookout could keep up. This would have been far less expensive for the customer since re-writing all of the PLC code is very labor intensive, therefore expensive.
You might want to include some warning that Lookout does not fully support the type of communications (mode 5 and 6) that involves lots of single read/write operations in medium density I/O situations. This way people could write their PLC code with Lookout as the highest priority instead of writing for PLC efficiency thinking that you could just attach Lookout to any I/O you wanted.
Again, this did not become a problem until we got beyond 250 I/O or so. Then as I/O was added to the system Lookout began to become unstable, until basically becoming unusable. (as it is now before we finish re-writing all the PLC code)
So, at the beginning we had no way of knowing how much of an issue this would pose for Lookout since we could go 6 or 8 months with ZERO communications errors, good frame counts in the 3 to 4 millions with no dropped frames.... Zero.
Foote Control Systems
We fixed the bug in 6.1 version, but didn't build the fix for previous version. Maybe I need to build it for 6.0.2 and put it on web.
For now, you can get it from ftp://ftp.ni.com/outgoing/, in folder modbus602. It is not an official release, but if it's urgent for you to get it, you can use this one.