Write To PLC

[PLCGuy]

Is there a way to write to the plc more than once? Once I write, it is greyed out. I wanted to write to the plc using different settings, but the only way is make a change in ladder, accept, the icon becomes visible then write it again.

[franji1]

No.

By "settings" I'm guessing you mean what is in the "Memory Image Manager"?  You can use THAT utility to update specific blocks of your Memory Image.

An alternative is the Memory View which you would set to NOT poll.  You can import (and export) CSV text files in your Memory Views.  Memory View is Data View except it's optimized for data-block access (vs. random access, which is what Data View allows).  You can have as many Memory Views open as you want (just like Data View).

[PLCGuy]

I was referring to the option, Force Download of Program & Documentation Database, when you write to the PLC.

I checked out the "Memory Image Manager". It scares me cause I do not understand all that is going on in there. lol Hate to mess something up in the PLC. I could write a practice program and play with "Memory Image Manager".

[franji1]

I wanted to write to the plc using different settings.

I was assuming that by "settings" you meant "data", meaning "Memory Image Manager".

If the "settings" you are talking about is a different "Program" or different "Documentation", the button SHOULD be enabled.  That would be a bug if they changed, Designer did not realize they were different and let you write to them.

Maybe I don't understand specifically what you mean by "different settings".

[PLCGuy]

I was referring to after you accept changes and click on the write to PLC a window pops up and you make choices how you what to write to the plc. So after I have a working program I want to write again to the plc. One of the things I want to do is pick Force Download of Program & Documentation Database. I did not pick that option the first time around but now I want to. I can not write to the plc cause i did not make any changes. Therefore the Write To PLC is greyed out and not available. the only way to get it to appear is to make a rung change, accept, then Write to the PLC so the window pops up and I can pick Force Download of Program & Documentation Database.

[franji1]

I get it.  Maybe we can make it an option or another menu item or ...

[BobO]

As part of our "ease-of-understanding" improvements, I really want to lose most of this. It's fine to have a smart write that allows for run-mode updates, but goodness, if the user tells us he wants to write the whole program, there is zero reason to disallow that.

In the end we really only need to determine whether a run-mode update is possible or not with the current modifications, and offer the option to write the memory image (which forces stop-mode xfer), and an option to force update of everything (which also forces stop mode). As long as the status line makes it clear that the PLC is up-to-date with DmD, there is no need to disable the Write to PLC button ever.

Might also be nice to reduce the status line difference indication to File:Same/Diff and PLC:Same/Diff, and maybe display the PLC:Diff in a different color if run-mode update is possible or not. Could also add a hover over the indicator that could give the full differences display for nerds who care.

[PLCGuy]

I care. lol. So it sounds like you are considering making some changes?

[BobO]

I care.

I would think that most users don't want to know or care whether the sysconfig or documentation or program or memory image needs to be updated, only that when you press the button to write to the controller that DmD makes it so. We'll still make it to where that information is readily available, but honestly, for most users it's just noise.

In terms of changes, yes, we are about to undergo a very significant makeover, with a primary focus on "ease-of-understanding" or intuitiveness. So much of what we do in DmD is "because we've always done it that way", without much thought into where the market is going (hint: many new PLC users weren't alive when DirectSoft was written). We believe the Do-more controller to be one of the best PLCs money can buy, but if we aren't winning new customers, we lose the war.

In the interest of intuitiveness, we feel that lots of the details we so proudly display, need to be hidden...they simply aren't that important, and the user really doesn't need to know. Look at an Apple product. Simple almost to a fault. We will never get there, but we need to move that direction because that's where our customers are moving.

[Garyhlucas]

This idea of intuitiveness vs need to know is starting to become an issue for us on the HMI side too.  First of all most of what is considered intuitive is not.  Eight sided polygon indicating stop.  That is a learned thing not intuitive.  What I prefer is the term 'discoverable'.  Standing in front of the screen with no idea of how it works can a person learn to make it work without causing a problem?  I hate icons, stupid little pictograms like Chinese. Many years ago I used to razz the 'expert' Lotus 123 experts by showing them the magazine ad with icons all the way around the border.  Even the best could never get more than 30% of them!

Right now my field guy is rapidly adding data and buttons to every screen to make it easier to get everywhere and see all the data.  I can see it from his point of view, he needs all that stuff to troubleshoot obscure problems.  I suspect though that our simple to run waste treatment plant is starting to look very complex to the operators.  So I am guessing we are going to need to makes a set of basic screens that are used by operators day to day, and an advanced set for troubleshooting and installation.

[BobO]

Technically it's all 'discoverable'...RTFM and such...but this is really semantics, we're talking about the same thing. After thinking about it a lot, we've come to the conclusion that most of DmD can be divided into 3 groups: Group 1 contains things that all users will do, Group 2 contains things that some/many will do, and Group 3 is relatively rare.

Group 1 things need to be obvious. I shouldn't need to read a manual to learn to do Group 1 things, and in the rare occasion that Group 1 things do require us giving you information (like learning to use the ladder editor) we need to be very proactive in doing so. At any point if I do a Group 1 thing, it should be clear what to do or where to go.

Group 2 things should at the least give you good crumbs as to where to go next. They may still require a small amount of research to use, but it should be very easy to get where you need to go and access what you need to access.

Group 3 is for experts. They don't need much help and generally take pride in knowing how to use stuff. I ain't worried about y'all.

One conclusion we came to is that Noobs should be sheltered from the complexity they absolutely don't need yet (or ever), so hide it. Intermediates need to comfortably access the 20% of the product they use consistently (aka Group 1 and Group 2) so make sure those things get lots of attention. Experts will find stuff no matter where you hide it, so don't feel bad about doing so if it helps Noobs and Intermediates.

Another conclusion we came to is that our typical approach is to "throw information at a problem". We've historically said "Do-more is easy, once you get over the hump", so we've tried to use information to do that. Wrong. Bulldoze the hump. So much of Do-more's architecture is irrelevant to 90% of our customers. Hide it. No one cares as long as they can solve their problem. So we are going to take a long hard look from the eyes of a 21yo straight out of school. What does he see and can we hold his attention long enough to win a customer? Doesn't matter how great your controller is if people get can't get over the hump.

Apologies to St. Francis of Assisi: Make sure your users know your product, and if necessary, use words.

[Controls Guy]

In the end we really only need to determine whether a run-mode update is possible or not with the current modifications, and offer the option to write the memory image (which forces stop-mode xfer), and an option to force update of everything (which also forces stop mode).

This sounds like a really good idea to me.

[Controls Guy]

Right now my field guy is rapidly adding data and buttons to every screen to make it easier to get everywhere and see all the data.  I can see it from his point of view, he needs all that stuff to troubleshoot obscure problems.  I suspect though that our simple to run waste treatment plant is starting to look very complex to the operators.  So I am guessing we are going to need to makes a set of basic screens that are used by operators day to day, and an advanced set for troubleshooting and installation.

Yeah, I think that's the solution.  If you can't make the extra information unobtrusive, then you need some kind of  Dial-The-Nerdiness feature users can adjust to match their interests or the task at hand.  That's the one part of the high performance HMI concept I agree with.  Cluster information on screens where you can adjust the detail level to suit.

[davidbgtx]

Right now my field guy is rapidly adding data and buttons to every screen to make it easier to get everywhere and see all the data.  I can see it from his point of view, he needs all that stuff to troubleshoot obscure problems.  I suspect though that our simple to run waste treatment plant is starting to look very complex to the operators.  So I am guessing we are going to need to makes a set of basic screens that are used by operators day to day, and an advanced set for troubleshooting and installation.

Yeah, I think that's the solution.  If you can't make the extra information unobtrusive, then you need some kind of  Dial-The-Nerdiness feature users can adjust to match their interests or the task at hand.  That's the one part of the high performance HMI concept I agree with.  Cluster information on screens where you can adjust the detail level to suit.

That's what I do screens for operators and then screens(password access) for techs. But even so one of my techs complains it's too complicated, so maybe I need 3 levels - operator, tech, and me

[PLCGuy]

Too avoid the "complicated" scenario, I take an operator or tech and have them try out the system. In most cases they might call something different then what I would use so I change it. Also, I might add something that is not really needed, so eliminate it. It is like a designer or engineer writing a operational manual, they understand it and and over look the obvious things that are not so obvious to the end user.  There again when ever I write a manual I have the operator run through it and make changes if needed.