Devicenet latency on output of pwrflx525 (poll cycle CoS confusion)

[Milestogo]

well I guess that either:
*my code is perfect and nobody has anything to add/suggest
or
*there's insufficient data to make any conclusion (Forgot to say that im using periodic scrolling for the routine)
or
*People don't know what to write when there are no specific question.

I think we can close this post then

 

[Ken Roach]

Please don't take offense: my criticism is of the software, not the people who wrote it !

I read that code in some detail, and concluded that it represents several iterations of attempts to deal in software with problems that arise from wiring and signal quality in this large, heavily laden network.

If it were my system, I would try to re-write a simpler MSG sequencer from scratch, and "wrap around" the diagnostic logic that measures performance and counts errors.

I think that the focus on "latency" is probably misplaced. The I/O scan is probably a hundred milliseconds at the most, so several-seconds-long failures of control of a PowerFlex drive cannot be related to network performance.

It is possible that the drive is losing its network connection entirely, and re-establishing it, which is why the start and stop commands do not function as expected. That problem should be addressed first.

In my opinion, getting the system to a stage where there are no misleading error codes that mask the actual problems is important as well. For example, if devices have been permanently removed from the network then their Scanlist entries should be disabled so that error messages related to them do not appear on the 1756-DNB display.

 

[Milestogo]

Thank you Ken !

I'm not easily offended don't worry, I'm here to learn!


We fixed the main issue by removing - as you said - the dead nodes.

Another problem was that the queue of msgs was too long so there was a latency between refreshed values.

ex: if current was too low at first, the next scrutiny would be 1500 ms later, and it triggered the under-current alarm.

This is why I removed the timer, so msgs would be as fast as can be.
Having the latency (or time between refresh of value) was useful to know so I do not put too many msg on the same counter.

Do you mean that there is another way to get those current value faster than msging? I think you suggested beforehand that I link the "current" parameter from rsnetworx to an available blank data on scanner ?

Thanks!