Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: fdiaz1 on February 09, 2014, 10:50:13 AM
-
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
-
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.
-
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 ;D
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.
-
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.
-
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.
-
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. ;)
-
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
-
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.
-
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.
-
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.
-
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...
-
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. :)
-
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! ;D
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.
-
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!
-
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.
-
I think the lower end platform would open a larger market for the Do More but I don't know about changing the programming model. How many programmers use all of the capability of DS or DMD, but it is there if you need it but you don't have too. I can see the need for the new system you are working on where lower I/O count, lower cost and smaller foot print is needed, but you may need all of the math, PID's ect. that the full size units have. If you had to dump some of the capability to keep the cost lower like the 05 vs the 205 (like less memory) I understand that. We already have to know the Click, DS, P3000, and DMD just for AD products, I would not like to have to remember, I cant use this command on this platform with the DMD software. But then again I have never built a PLC of written programming software for them and you have. (and a very good ones at that)
-
I think the lower end platform would open a larger market for the Do More but I don't know about changing the programming model. How many programmers use all of the capability of DS or DMD, but it is there if you need it but you don't have too. I can see the need for the new system you are working on where lower I/O count, lower cost and smaller foot print is needed, but you may need all of the math, PID's ect. that the full size units have. If you had to dump some of the capability to keep the cost lower like the 05 vs the 205 (like less memory) I understand that. We already have to know the Click, DS, P3000, and DMD just for AD products, I would not like to have to remember, I cant use this command on this platform with the DMD software. But then again I have never built a PLC of written programming software for them and you have. (and a very good ones at that)
The current thinking is that a DM1 is always a DM1, so if we put a DM1 on a low end platform, it would still be capable of everything the current CPUs are capable of. The better way to think about it is more like a Novice Mode and an Expert Mode for all DM1s, regardless of platform. The emphasis in Novice Mode would be to reduce the complexity to a level that a new guy with no experience could handle. If the basic stuff does the job (and it would in many cases) keep using Novice Mode as long as you like...but...when you hit a wall (which happens often with a very low end PLC), you can take off the training wheels and go to Expert Mode. Once riding without help, I seriously doubt anyone would go back.
As technology moves forward, kids coming out of school are much further away from something like a PLC than I was coming out of college in the 80s. It is imperative that we find ways of adapting to those changes and find ways to meet new users where they are. How do you reduce PLC programming to something that you could put on an iPad and can be used by a kid graduating in 2015? Answer that question well, and be successful for the next 20 years. Fail, and...well...that simply isn't an option.
Again, all of this is very preliminary and just brainstorming. For the same reason that I do my work on a desktop, running development tools that were natively compiled, producing code that is natively compiled, I think the Big Boy package will always be used by automation professionals, and as new folks become experts, that's where they will wind up. I just want to find ways to increase the number of automation professionals that use Do-more!!
-
I understand your thinking, I think you are on the right the easier you make the systems to use the larger the possible user base. By doing that (getting a larger base) I think it will be an easier sell to some of the hard line guys that only want X or Y brand. If you can get the program to work in an Ipad I can get my grandson work with them (I think he sleeps with his Ipad and phone) ;)
I agree you have to get the product in the hands of the people that use it with the tools they prefer to use. A lot of our customers want to run their machines with an Ipad or Android tablet as the HMI, we are working on how to do this better. Younger workers are more comfortable with them.
I just wanted to voice my concern that old farts like me will still have our toys to play with also. ;D In our company we try to keep thinking how to make it faster, easier, better, stronger, cheaper and more marketable, sound like we are not the only ones! Keep up the great work.
After I made him use DmD and the Do-More on a project, we have a Allen Bradley programmer in our shop that (without being forced too) recommended using Do-More on a project to one of our customers :o that's like the Yankees rooting for the Cubs!!
JW
-
I just wanted to voice my concern that old farts like me will still have our toys to play with also. ;D In our company we try to keep thinking how to make it faster, easier, better, stronger, cheaper and more marketable, sound like we are not the only ones! Keep up the great work.
As Host's Old Fart in Chief, I do solemnly swear that I will not take away your toys, but will in every case reasonable, give you more and better toys to play with. If it helps any, our primary vision in developing Do-more was to build the controller that *we'd* want to use. That vision has not and will not change, although in becoming more aware that *we* are not the customers we will be selling to in 20 years, we are looking for ways to make it easier for the young guys coming up.
-
After I made him use DmD and the Do-More on a project, we have a Allen Bradley programmer in our shop that (without being forced too) recommended using Do-More on a project to one of our customers :o that's like the Yankees rooting for the Cubs!!
Is this the guy that believes that when you die, you go to Milwaukee? ;D
-
That's him, he still sip's the cool-aid, but we have him tasting the sweet tea! ;) He mainly works on large already in place networked AB systems, PLC5, SLC, Controllogix with DH+ ::) and Ethernet (large plants). It is a hard sell to get these guys to think about anything other than AB but we did get our guy talking about Do-More so anything is possible.
JW