ATO Malfunction

[Gunther]

On your screenshoot you have cut the the most important thing: What number is selected below "Used sensor for this control" on bottom?

[Tone]

Read my post above, I tell you that it is "6". BTW, I didn't cut it off, your software did.

In PLC 5.13 the sensor is changed to 6 and this is how it looks in PLC 5.13

[Gunther]

Read my post above, I tell you that it is "6".

I had overseen that. Sorry.
Change it to "1" if your float is connectet to the first level sensor,
"6" is not present in a system without Expansion box or -card

BTW, I didn't cut it off, your software did.

Surely not.

[Tone]

Thank you, Gunther.

I checked the jpg in my picture folder and it is full size there. These things happen. It doesn't matter.

I have previously changed the optical sensor to #1 and it hasn't worked.

What I will do now is to reflash the firmware and reload the PLC, then I will change the sensor to #1 and see what happens ... maybe with the changing of things 'out of sequence' the P3eX has got confused.

[Tone]

OK completed reloading tasks and reset the sensor to #1 ... and so far so good, the sensor has not triggered an alarm.

I'll keep a tab on it and confirm tomorrow if the operation is fixed.

[Matthias]

Is there an explicit directive from GHL in respect of the compatibility of the firmware with particular versions of the PLC ? ... it seems that there is none. If the 'mismatch' that I find is "not a good idea" then please direct me to the clear instructions from GHL that require the PLC to be upgraded to work with FW5.13 ... You will be aware that there have been many firmware upgrades in the past that do not require PLC upgrade and that this has been made clear.

the startup-screen of ProfiLuxControl gives the information:
"This version supports .... ProfiLux 2 and 3 ... with these versions: x.xx to x.xx"

I think this is clear enough, isn't it?

Coming back to your problem

please do not forget that the optical sensor worked perfectly before upgrading firmware from 5.12 to 5.13.

this can be a coincidence - is strange but happens

First we have to check if the sensor is working at all, therefore go the level dialog and check the states of the level sensor inputs:
LevelATOproblem.jpg
The state (direct) shows what the level sensor recognizes (yellow marker)
Make a test, put the sensor into the water, remove it and check what happens with that state. Let us go from there.

[Tone]

Please understand my frustration that I don't want to find 220L of RO/DI from the reservoir dumped into my long-lived 2,000L sps display.

the startup-screen of ProfiLuxControl gives the information:
"This version supports .... ProfiLux 2 and 3 ... with these versions: x.xx to x.xx"

I think this is clear enough, isn't it?

I disagree, that is reverse logic ... 'putting the cart in front of the horse.'

The note regarding PLC versions should appear as an appendix to the firmware version that is to be downloaded. "This version of Firmware x.xx requires upgrade of the PLC to version y.yy" In this case the customer is adequately forewarned that the version of firmware that they are downloading will require a corresponding upgrade of the PLC version for proper operation. It might be a little inconvenient to GHL but believe me that it will be of immense benefit to your customers.

Another thing, you have a perceived expectation that all of your customers have the 'programmers understanding' of the intricacies of the firmware and software. This is not the case so it would be immensely helpful if a 'readme' note is attached that draws the customer's attention to the changes and what further adjustments need to be made to ensure the ongoing operation of the holistic system -- I don't wan't to find my display compromised due to incomplete instructions regarding upgrades. The current upgrade history file is fine for the programmer but of little use to the customer as it is significantly incomplete in explaining the changes and ramifications.

Communication is of utmost importance.

Getting back to the problem, the action that you describe is the course of action that I have been following ... however, having wasted much time and energy with not knowing that the PLC also required to be upgraded ... which is now done. In addition, as explained in my previous post, I have reflashed the FW and reloaded the PLC to ensure that there is no residual conflict from the previous attempt at getting the combination to work adequately.

Gunther has also kindly advised me that the sensor should be reset to #1 ... it defaults in the upgrade to #6, why does it do that and not default to #1 which would be logical ? I might add that prior to reloading the FW and PLC, I did do this and the operation at #1 also failed and produced an 'alarm' state.

Since reloading the FW and PLC the operation appears to have corrected and I am now closely monitoring it -- so far so good.

Thank you for your attendance, Matthias.