Eric Kirchner (Customer) asked a question.
I have many instances where I allow the range of a Setpoint to be 0 to XXX (let's say 0 to 10), where although 0 is a valid entry, it is WAY TO EASY to pull up the entry field, and decide you don't want to change it, hit ENT and accidently change it to 0. The ease of which it is to set a value to 0 is DANGEROUS.
One solution is to limit the lower value to 0.1 or some small positive number. Though this does work, it's not valid for many cases (let's say it's a bipolar value, zero would be a valid entry).
If I look at the default keyboard (EA9 System Default 1). The displayed value (i.e. current value) will load with "0" even if the current value is something other than 0, 25 in the below example.
It is dangerous to have a value default to something other than the current value. How can this value be pre-populated?
I do not like the handshaking option. How do I have some sort of "Value will Change" Confirmation or something that prevents this easy accidental change from happenening?
One option that might be easy if it were an option is to hide the ENT button when "SYS KEYPAD VALUE" = "SYS KEYPAD CURRENT" however this type of comparison isn't an option.
These internal tags aren't available to the Event System, where a background periodic script could watch the value and flag a "Different" tag that the "ENT" button could watch, but I can't do that either.
I usually use arrays for settings, I think of them as recipes. Not your typical CMore recipes.
In the PLC (usually P3K or P1K) I would have two arrays for the recipes.
In the recipe editor, I allow the user/tech to make changes. After an 'editor' tag valueis changed, it will be different from the 'runtime' value, I have some indicator that clearly shows that some value changed -- a value is 'dirty.'. (You could have a bool array to indicate which Numeric Entry Object values was changed.)
I also have LOAD and SAVE buttons that are based on the dirty state of the 'editor' tags.
Imagine: (for this example, all the values are S32.)
One array that holds all the 'runtime' values.
One array that holds all the 'editor' values.
One HMI screen that has a Numeric Entry Object for each 'editor' value.
One tag for 'Load', one tag for 'Save', and one tag for 'IsDirty'
On HMI:
use the 'editor' tags for the Numeric Entry Object value tags.
Have 'Load' and 'Save' buttons and an 'IsDirty' indicator.
'Load' button is always visible.
'Save' button visibility tag is 'IsDirty'
In PLC:
When you enter the editor, activate the 'Load' tag once. -- copy the 'Runtime' array values to the 'Editor' array.
While you are in the editor, compare the two ('runtime' and 'editor') arrays. If any indexed entry pair is not equal, turn on the 'IsDirty' tag -- which indicates a change -- and enabled the 'Save' button.
On 'Save' button, copy the 'Editor' array values to the 'Runtime' array.
This 'Save' copy will then reset the 'IsDirty' tag because the comparing of the arrays will result in NO TAG CHANGE.
This is a bit simplified, but is workable.
Thank you @kewakl (Customer) , we are using DirectSoft here for what it's worth. I am not in favor of having 2 sets of tags for all numeric entries. It's hard enough to optimize the tag reads over modbus already, the more tags the slower the HMI will get.
But that is an option. Seem complicated for something that is, in my mind, a simple bug in Cmore, to not auto-populate the Numeric Entry Field.
I agree that the approach that I described is overkill for your problem.
I agree that the problem you described is an issue.
I don't see CMore getting the 'fix' you desire in a timeframe for your project.
The facility I am at now has gone cheap, and is all AD based (for larger / newer equipment that will migrate to ControlLogix, which the Productivity Series is a very poor clone of, and not very much cheaper). I might consider keeping the CMore Platform though, as it does what I need for the money. There are some really weird bugs that drive me nuts, like transparency for objects and not for others. But it combined with a Clogix isn't a horrible platform. This Numeric Entry issue has caused my maintenance guys to say #$#$## many times realizing they just lost their setpoint.
I think my solution will just be to make anything I can Lower Limit > 0 until there is something more convenient. (only a problem where 0 would be a valid setting)
"not very much cheaper"
CLX and Productivity (2000 and 1000 especially) aren't even close to being the same price. Especially when considering software costs.
@RBPLC (Customer) sorry, you are correct, I should have said Compact Logix.. Which feature for Feature is a substantially superior platform. I have a full price comparison, including software somewhere, if you would be interested. I just don't know where it went. It surprised me how competitive the platform is. Yes Control Logix is on a whole other level, but the usability remains in the "entry level" platform.
You have to also consider the cost of Rockwell's "Tech Connect." I find it total BS having to "pay" to get technical support. This is Rockwell price gouging its customers. So, to avoid the cost you have to rely on the local distributor's "product specialist," who is already overworked by all the other smart customers who don't bow to Rockwell's greed.
I'll take AD over Rockwell any day.
What I do in these instances is add a separate "Accept Edits" pushbutton. So, the operator would type a value and hit enter from the keypad, the keypad disappears and then would have to depress an additional "Accept Edits" pushbutton for the new values to overwrite the old. Had to do this for years when using A-B Panelviews.
@Todd Dice (Customer) , why did you have to do this for AB Panel Views? I have never had to do this, maybe I never noticed the issue or maybe I forgot (maybe in the PanelMate days?, or maybe I have been using PVP+ so long I have forgotten??)
I had the Panelview overwrite settings to zero whenever opening the recipe edit screen. I thought it another anomaly (annoyance) of A-B. This was during the SLC500 days so who knows, maybe in later revs of Panelview software Rockwell fixed this. I've been programming PLCs/HMIs since 1985, so your results may vary.
Edit: I should mention I never had the Panelview issue with TCP and CTC HMIs, the "state of the art" HMIs of the 1990s. 😄