Lookout 6.0.2 modbus rtu problem?

[Ryan.S]

rfoote,

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.

[rfoote]

Ryan

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.

rf

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.

[rfoote]

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.

Roger

[Mike@DTSI]

A quick way to check for a frozen update member.

Get all of the objects and create a delayon timer.

mb1=Modbus object

SiteActive can be a simple switch

Enable= (mb1.update+mb2.update+etc)=(SiteActive1+SiteActive2+etc)

Delay=20:00

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.

Mike

[rfoote]

Mike

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.

Roger 

[Ryan.S]

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.

Two possibilities.

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.