Do-More sometimes makes U do more

[fdiaz1]

I feel the Do-More is a very productive platform with many time saving elements. However, there are a few things that make me work harder.
Timer preset units.
Why does the constant preset box give a range of time units (hr, min, sc, ms) yet the variable box is fixed to ms? If I have an HMI with a numeric entry (for the timer set point) in minutes, I would have to either add more code to  multiply the tag value in to ms's then write the new tag in to the timer set point, or I would have let the operator enter 1800000 ms instead of 30 min. The same applies if I want to display the timer's acc value.

Element Browser
If I double click on a rung because I want to add a C bit element the small window comes up, usually with an element already inserted. I typically click on the browser icon and when the element browser opens I would like to select a C bit that is not currently used in the program, and enter the nickname, description etc. Currently I wont know if the element that I am choosing is already used or not. I know there are other ways; I could enter a nickname and have the "create nickname box" come up with the option of "assign to first unused element...". But what if for what ever reason I don't want to use the next element (C666). There are times when I like to group C elements in sections, like C0-C100 use for function X... Besides my reasons, I believe if there would be at least a box in the element browser that is checked when the element is used, it would be valuable info. I am not to fond of the Xref, but I am not getting in to that now.

I read some posts that trash the productivity of the Click vs the Domore, but the Click solves both issues above. and I encounter both issues repeatedly from start to finish of a project. If I am overlooking something that would help me please let know.

Respectfully,
fdiaz1

[BobO]

DL controllers use either a 10ms or 100ms timebase and 16 or 32 bit accumulator. We chose to use a 1ms timebase and 32 bit accumulator to keep the design as fast as possible. For constant presets, we allow you to enter the value in h:m:s:ms and convert it automatically, although the instruction still uses milliseconds. Variables must be in the underlying timebase, hence must be in milliseconds.

I am unfamiliar with CLICK's instruction set, but it sounds like they chose to allow you to specify the timebase. We honestly didn't consider that it was a big deal, but I'm sure we could add it. What timebases do you think need to be supported?

As for the issue of element selection, the Usage view is the best way, although admittedly we should have added some mechanism to access that information with within the element browser. When we developed Do-more, our primary emphasis was in developing an elaborate and powerful instruction set. We honestly didn't put much effort into changing or improving the editing facility itself, choosing to use existing DirectSoft facilities where possible. We definitely have plans to begin improving the editing facilities now that we have the controller well established.

I won't argue the merits of CLICK vs Do-more. They are completely different products with completely different goals. Do-more's emphasis was power and flexibility, CLICK's was simplicity. 'Simple' will always be easier to use than 'powerful', that's just the nature of design compromise. That said, I'm sure that there are things that we can do to make Do-more easier to use, and that is definitely an emphasis for the future.

Thanks for the feedback.

[fdiaz1]

or I would have let the operator enter 1800000 ms instead of 30 min. The same applies if I want to display the timer's acc value.

What timebases do you think need to be supported?

I would like to get the option of selecting between ms, sec, min within the timer. I am not looking to change the speed/accuracy of the design, what I am suggesting is pre-written internal code to display the internal ms value to a selectable timebase.

As for the issue of element selection, the Usage view is the best way

Where do I find the "Usage View"?

If there could be extra columns in the Documentation Editor for "Used" and "Retentive", I would be happy. Even better if from the Element Browser (E.B) there could be a button that takes me to the Documentation Editor and the last selection would follow back to the E.B which would follow back to the rung. Then I would be in heaven 

I hope that I am not coming across as if I am trying to change your product into a Click, because that is not the case. In fact there are a ton of things I prefer from the Do-More than the Click not even related to performance.

I just finished a healthy sized project with the Do-More and I was very pleased. I just feel there are a few areas in the software that can be improved. Of course the Do-more is hands down 100% better than Direct Soft.

Thank you for accepting feedback.

[ATU]

I prefer to have one timebase on the timers. It gets to be confusing having to go behind someone's code having multiple time bases, especially when dealing with HMI tags. Omron has a different timer instruction for every timebase, what a mess to deal with. Interestingly Rockwell had multiple time bases in the SLC500 package, but chose to go to a single ms timebase in RS5000.  In this case, I vote for simple.

[plcnut]

I agree with ATU, keep it simple: One timebase.
Use MATH, SCALE, FmtTmr() or do the scaling in your HMI.

Where do I find the "Usage View"?

Open XRef View, and click the second button from the left.

[BobO]

I hope that I am not coming across as if I am trying to change your product into a Click, because that is not the case. In fact there are a ton of things I prefer from the Do-More than the Click not even related to performance.

I didn't take it that way at all. We learn in contrast. I didn't know how bad DL was until I had been programming Do-more for a while and went back. When you program both Do-more and CLICK, you clearly see the things that each does better. We probably should have put more time into the timer instructions, and obviously the CLICK team did. Given the very small instruction set, it makes very good sense that they could put a significant amount of time into each one, and I'm certain we can learn some things from them.

Thank you for accepting feedback.

Can't improve what we don't know needs improvement. Can't quote the verse, but I'm pretty sure there is one about it being wise to accept correction...or perhaps foolish to refuse it. Either way, we always need to listen. Feel free to tell us, even if you think we don't want to hear it.

[fdiaz1]

Where do I find the "Usage View"?

Open XRef View, and click the second button from the left.

Thanks plcnut, i was able to find it... But a bit disappointing, no tags.

I agree with ATU, keep it simple: One timebase.
Use MATH, SCALE, FmtTmr() or do the scaling in your HMI.

You would really want to have an extra tag and extra code when all you have to do is select a timebase at the timer? To me that's not keeping it simple. But I respect everyone's methods.

BobO, I really appreciate the sincere responses to feedback from this forum and your products. I see in other forums when there is a suggestion and the staff gives a robotic answer ("I will pass it to the product manager").
Even if I don't ever see changes to the element browser or timer select able timebases, I feel like I have been heard.
Thanks

[Controls Guy]

Yes, AB did do that, but I've disliked the timers ever since over exactly that issue.

OTOH, I also don't like the brands that have separate instructions for different timebases. (DL Classic, Omron, Idec has like FOUR I think!  Really??).  Some makes use IEC time (T#1h3m5s), which formats constant setpoints to human readable form like Do-More, but it's hard to write to their setpoints. Bottom line, it's kind of an awkward issue.

Your point about HMI's is well taken, ATU.  With multiple timebases, the HMI has to know something about the PLC program to know how to scale a setpoint or accumulator display.

Thinking how to respond to this, I realized the only thing I don't like about the AB timers (32-bit ms setpoint), isn't that they're single resolution, nor the specific resolution, but the fact that they don't scale the setpoint (program and runtime) or the accumulator value (runtime) for the ladder display, so you can't just look at it and immediately know "Oh, it's about a 36-hour timer, with about 18 hours elapsed".  I want to be able to input time in days, hours, etc., and to read both setpoint and acc value in those terms at runtime, which is exactly what Do-More does, even if you use a variable setpoint.  Having a single resolution is good for the HMI, as noted, and scaling setpoints and acc values in the HMI is pretty trivial.  So I'd say Do-More is already the optimal solution, and AB is about 90% of the way there.

[BobO]

It would be an easy thing to add the timescale to a variable preset...in a *new* instruction. Unfortunately, the existing timer instructions don't allow for any options in the opcode, so changing them would be very painful. Adding a prescale to the preset value wouldn't affect the actual timebase, it would just include the math to convert to milliseconds before using it.

We have talked about creating a 'lite' mode for Do-more that would simplify it down to a CLICK-like instruction set. If we eventually do pursue that, we would likely create a new timer instruction (like maybe...TIMER) that would work very much like CLICK's single timer instruction. That may happen, but we've got a few new things to get out first.

[Controls Guy]

It would be an easy thing to add the timescale to a variable preset...in a *new* instruction. Unfortunately, the existing timer instructions don't allow for any options in the opcode, so changing them would be very painful. Adding a prescale to the preset value wouldn't affect the actual timebase, it would just include the math to convert to milliseconds before using it.

That would address some of the cases, but you'd still have a single setpoint, be it in hours, days, ms, etc., so it still doesn't help with the 1h3m12s case, just gives you 192 hours as an option for example.  I think you have it about as good as it can be right now.  You've already got the 99% solution.

We have talked about creating a 'lite' mode for Do-more that would simplify it down to a CLICK-like instruction set. If we eventually do pursue that, we would likely create a new timer instruction (like maybe...TIMER) that would work very much like CLICK's single timer instruction. That may happen, but we've got a few new things to get out first.

Sounds like a lot of work that could be used to add more powerful features.  There's already Click's available for sale, no use competing in that niche IMO.

[BobO]

Sounds like a lot of work that could be used to add more powerful features.  There's already Click's available for sale, no use competing in that niche IMO.

If I were to sell lower end platforms and offered a simplified programming model, I believe we could expose Do-more to a far larger customer base, especially if the simplified model could be seamlessly upgraded to the full product. We have no intention to cease developing cool new stuff...but...I don't think I'm losing much business now because of what Do-more cannot do, but I'm pretty sure many customers are not choosing it because they feel it to be complicated. I think we sell more Do-more if we can lower the perceived cost of entry. Think of it as running the football to enable the pass...

[Controls Guy]

If I were to sell lower end platforms and offered a simplified programming model, I believe we could expose Do-more to a far larger customer base, especially if the simplified model could be seamlessly upgraded to the full product.

Interesting possibility.  Hope so.  Well, you guys obviously know what you're doing as Do-More attests.   

[BobO]

Interesting possibility.  Hope so.  Well, you guys obviously know what you're doing as Do-More attests.   

Maybe. I can totally build a PLC, but this whole business thing is another deal altogether!

It could be a complete failure...but I don't think so. As a TI employee, I watched them systematically destroy their PLC market share by doing cool stuff in high end equipment, all while ignoring the low-end 5TI that put them on the map. Ironically it was a relatively unknown Japanese company named Koyo that used the 5TI as inspiration to develop their first PLC, that was eventually re-branded as the GE Series 1...which became the best selling PLC in the world. I won't make that same mistake. New ones? Probably.

[Controls Guy]

I don't think I'm losing much business now because of what Do-more cannot do, but I'm pretty sure many customers are not choosing it because they feel it to be complicated.

I probably misspoke when I said "powerful".  One of the things high on my list would be the tabular data view and simplified writing/forcing, so that's more of an ease-of-use thing that would benefit users of all skill/experience levels than increase Do-More's power per se.

Also, an upgraded UI on the named constants, work on string display a little, etc.

So it looks like a lot of my wishlist has more to do with the editor UI than the PLC itself.

See, now you're forcing me to think so I can actually say what I want to see!

[BobO]

I probably misspoke when I said "powerful".  One of the things high on my list would be the tabular data view and simplified writing/forcing, so that's more of an ease-of-use thing that would benefit users of all skill/experience levels than increase Do-More's power per se.

We were actually considering the 'lite' environment as the best place to develop and road test such things. The problem of DmD and its DirectSoft legacy is that we have a huge user base and a 20 year history. Every change we make invites trouble, even if the majority view it as an improvement. A clean-sheet environment gives us the freedom to innovate, with the intention of propagating the best stuff into DmD. Like the tag picker/xref/usage/documentation thingy that prompted this thread...while I'm not sure how to answer that question in DmD, I am pretty sure we can clean-sheet a better editing environment. If well received, DmD gets the same stuff at the next release...but if deemed a poor effort, I don't hurt my flagship.