Please tell us what your experience has been with Do-more...

[mhw]

Just getting started with my first do-more project. First disappointment, nicknames. BobO says we should be using nickmanes instead of actual memory locations. I think it is a great idea, so why did you narrow the available nicknames? We are still limited to 16 characters and special characters such as "?!" are no longer allowed.
With DS5 I would use "CONVEYOR1_ON" as an output, "CONVEYOR1_ON?" as an input, "CONVEYOR1!" as a fault.
How do others handle nicknames?

[BobO]

Just getting started with my first do-more project. First disappointment, nicknames. BobO says we should be using nickmanes instead of actual memory locations. I think it is a great idea, so why did you narrow the available nicknames? We are still limited to 16 characters and special characters such as "?!" are no longer allowed.
With DS5 I would use "CONVEYOR1_ON" as an output, "CONVEYOR1_ON?" as an input, "CONVEYOR1!" as a fault.
How do others handle nicknames?

First, I greatly regret our decision to stick with 16 characters. The decision was made early in the development long before we had a clue of where this was going. In retrospect, it was a very bad decision. It's something that can be changed though, and we might address it in the future.

The loss of special characters is easy to justify though. Math in Do-more uses real expressions like any high level language. It was necessary to restrict nicknames to something similar to a C language symbol to make those expressions possible. There are no limitations on the extra info or description fields though.

[Controls Guy]

mhw, I never bothered with nicknames (unique ID's that can actually be used in lieu of an address) specifically because they're too short and too constrained to store a description that I'd like.

So I've always just used native addresses, but with good descriptions (multi-line free form text that doesn't have to be unique and which can't be used as an address).

With Do-More, I expect to do the same thing, except that a lot of things in programming lend themselves to the use of structures, or user-defined data types.  I'll probably use heap items where that makes sense, which is kind of analogous to using nicknames vs. native addressing, in the sense that they're named more functionally rather than with reference to their storage location.

BobO, can we do free-form UDT's in heap yet, or just one-type arrays for now?

[BobO]

mhw, I never bothered with nicknames (unique ID's that can actually be used in lieu of an address) specifically because they're too short and too constrained to store a description that I'd like.

Old school, like Bernie. No criticism here...I want you to do what works best for you...but I have a hard time wrapping my head around the thought that you would find WX32 or X129 easier than names like CoolingBathTemp or FwdCarriageLmt, or that you would consider those names to be of limited value. I've been coding for 30+ years, and 80% of the variables I use in code are 16 characters or less, and 95% or more are 20 or less. Even though C++ doesn't impose any meaningful limit, code readability dictates that concise names are better.

BobO, can we do free-form UDT's in heap yet, or just one-type arrays for now?

User defined types are on the road map, but are not there yet. DmD would fully support then now, but the UI and project management/portability issues have to be resolved. Dynamic is cool. It is also a major pain in the rump to make work properly.

[Controls Guy]

Old school, like Bernie. No criticism here...I want you to do what works best for you...but I have a hard time wrapping my head around the thought that you would find WX32 or X129 easier than names like CoolingBathTemp or FwdCarriageLmt, or that you would consider those names to be of limited value. I've been coding for 30+ years, and 80% of the variables I use in code are 16 characters or less, and 95% or more are 20 or less. Even though C++ doesn't impose any meaningful limit, code readability dictates that concise names are better.

[shrug] I don't know -- I find the misspelled/abbreviated names with no spaces unpleasant to look at, and the numbers aren't that hard to remember (especially with a printout of my Excel memory map design right there on the desk).  In sort of a similar vein, I barely do comments.  I do the descriptions well enough that you can look at the rung and tell what it does, and I get all that for free just from having written the descriptions once (or it would work with nicknames too), so why bother with comments, except in unusual cases (or to mark off code blocks)?

User defined types are on the road map, but are not there yet. DmD would fully support then now, but the UI and project management/portability issues have to be resolved. Dynamic is cool. It is also a major pain in the rump to make work properly.

Looking forward to getting them, but understand that you guys need to take the time to do it right.

[BobO]

I would say that the benefit of well described points vs not needing comments speaks heavily of the type of applications you do and/or the way you code them. Certain problems are inherently state based, others are sequence, and still others are algorithmic...and perhaps more to the point...different folks approach problems in different ways, and the same person will approach the same problem in different ways with different tools. I'm sure that I would write different code than you, and the Do-more code I write bears little resemblance to DL code I write.

Meaning, there is a whole lot of adapting going on...and there is nothing right or wrong about it. Use what works for you.

[franji1]

I used to write comments "for the other guy, who might have to figure out what I'm doing".  Over the past few years, I do it for the same reason, it's just "the other guy" is ME!

Who here remembers their last Senior Moment?  Anyone?  Anyone?  If you do, then it wasn't a Senior Moment.   

[Controls Guy]

I would say that the benefit of well described points vs not needing comments speaks heavily of the type of applications you do and/or the way you code them. Certain problems are inherently state based, others are sequence, and still others are algorithmic...and perhaps more to the point...different folks approach problems in different ways, and the same person will approach the same problem in different ways with different tools. I'm sure that I would write different code than you, and the Do-more code I write bears little resemblance to DL code I write.

Excellent point.  I'm sure that's exactly the case.

[Controls Guy]

Who here remembers their last Senior Moment?  Anyone?  Anyone?  If you do, then it wasn't a Senior Moment.   

LOL -- if you get them often enough, they sort of merge into a "stream of unconsciousness"!

[nfei]

Hi Bob,
I spoke with Greg late last year trying to decide to make the move the Do-More. I have a 8 unit system that must work with an existing Lookout system. Greg talked me through getting it to work but now I cannot repeat getting the "C" objects to write to the "DLC" objects in Do-More. I am using the MOVER to get V data out but I am stumbed on the C bit control. If I cannot make this work ASAP, I will have to revert back to the DL205 series!
HELP?

[BobO]

Hi Bob,
I spoke with Greg late last year trying to decide to make the move the Do-More. I have a 8 unit system that must work with an existing Lookout system. Greg talked me through getting it to work but now I cannot repeat getting the "C" objects to write to the "DLC" objects in Do-More. I am using the MOVER to get V data out but I am stumbed on the C bit control. If I cannot make this work ASAP, I will have to revert back to the DL205 series!
HELP?

I'm actually on vacation right now and I think Greg is too, but hopefully Mike or Franj or somebody else there can talk you through it. I would even be happy to help, but I have no phone and limited internet. If you will PM a phone number to one of us, we'll call and talk you through it.

[Electron]

I just completed my first large Do-more project 2 PLC's, 300+ inputs, 4 citrio counters, 10 analog channels.  I wrote the HMI's in VB.net, comms were Modbus TCP.

Requests:
Expand the Do-More to include all 205 hardware available, or at least more common ones.....even just for the convinence of not having to research which specific devices are compatable and are not.

For some expansion, I prefer using the D2-CM/EM over the ERM/EBC100. I am new to using the ERM and dont use all of its functionality, but my take is:
Addressing expansion modules with the ERM should be more automatic and built into the Do-More Software along side the base I/O addressing. As well, addressing ERM Expansion should use decimal addressing.   The ERM/EBC definately have their place, but if I need an expansion rack right next to my base, the D2-CM/EM seems cleaner, faster, easier, and cheaper.....like it is in the 205.

I have been in many endless arguments about data tag labeling and mapping...but at the end of the day, it is inefficient organizing data by type.  I would prefer to be able to label a tag whatever I want, select what data type it is (to include I/O, but I understand structures there), select retention, etc,  and then organize my tags alphabetically. If I wanted them organized by type, then I would prefix the name of the tag as such. If I need to know from the name if a bit is an in, out, or bit...then I just put a X,Y,C in the name as I see fit, otherwise I will look at the data table for more info about its structure. Nicknames almost serve this purpose...if I could organize the xref by nicknames I would be happy, but also, need to expand the # of chars, and types of chars for nicknames.

If we are going to continue organizing by type.....do it alphabetically, or at least have the option.  The list organization of the Xref chart slows me down from finding my tag. I roughly know how it is organized when I am looking for common tags: X,Y,D,R,T,C....but if the whole thing was alphabetical, my time to find a tag xref would be significantly decreased.

Sometimes its the little things...I do find that mouse scrolling up and down in the ladder logic is jumpy...and sometimes unpredictable?  I find myself getting lost, overshooting, undershooting,  mostly when I have to be on a laptop and have a smaller screen....but it seems like the up and down could be rethought or smoothed out somehow? I think because it jumps in increments of rungs, which aren't always the same height, my eyes have a hard time following a rung in its movement.  Maybe the scroll needs to be consistant smaller lengths to smooth it out.

Just throwing my 2 cents in, which might be a repeat of what others have said..but this is me voting on what I would improve initially.

The Do-More software and Hardware is a major improvement.  As well, it is a step in the right direction, keep going with it. I am an extremely satisfied customer, and will always use a Do-More PLC for every application I can apply it to.

[BobO]

Requests:
Expand the Do-More to include all 205 hardware available, or at least more common ones.....even just for the convinence of not having to research which specific devices are compatable and are not.

What is not supported that you wish to use (other than EM/CM)?

For some expansion, I prefer using the D2-CM/EM over the ERM/EBC100. I am new to using the ERM and dont use all of its functionality, but my take is:
Addressing expansion modules with the ERM should be more automatic and built into the Do-More Software along side the base I/O addressing. As well, addressing ERM Expansion should use decimal addressing.   The ERM/EBC definately have their place, but if I need an expansion rack right next to my base, the D2-CM/EM seems cleaner, faster, easier, and cheaper.....like it is in the 205.

Ironically, the reason we chose not to support the EM/CM was precisely related to your first point. There are too many limitations with EM/CM in performance and supported modules. After discussions with the product manager at ADC, the decision was made to not support. Knowing that people would need to expand systems, however, we have always planned to support I/O expansion through the built-in Ethernet port. Which...

...as of version 1.1, to be released in the next couple of weeks, you will have fully native support for up to 16 slave devices. Slaves can be H2-EBC100, T1H-EBC100, and GS-EDRV100. The entire thing is very clean, high performance, and all associated I/O looks exactly like modules in the local rack...including CTRIO/2 support in both 205 and Terminator racks.

I have been in many endless arguments about data tag labeling and mapping...but at the end of the day, it is inefficient organizing data by type.  I would prefer to be able to label a tag whatever I want, select what data type it is (to include I/O, but I understand structures there), select retention, etc,  and then organize my tags alphabetically. If I wanted them organized by type, then I would prefix the name of the tag as such. If I need to know from the name if a bit is an in, out, or bit...then I just put a X,Y,C in the name as I see fit, otherwise I will look at the data table for more info about its structure. Nicknames almost serve this purpose...if I could organize the xref by nicknames I would be happy, but also, need to expand the # of chars, and types of chars for nicknames.

I won't argue or debate this, except to say that Do-more is, cool new features notwithstanding, a conventional PLC with a conventional PLC view of memory. Our efforts to expand the more tag-centric features tend to get us verbal abuse from those who don't like them. That said, we do have plans to create one or more new views that should be more appropriate for tag-centric people, and we will certainly consider your feedback when we spec them.

Sometimes its the little things...I do find that mouse scrolling up and down in the ladder logic is jumpy...and sometimes unpredictable?  I find myself getting lost, overshooting, undershooting,  mostly when I have to be on a laptop and have a smaller screen....but it seems like the up and down could be rethought or smoothed out somehow? I think because it jumps in increments of rungs, which aren't always the same height, my eyes have a hard time following a rung in its movement.  Maybe the scroll needs to be consistant smaller lengths to smooth it out.

Mouse scrolling is definitely an emulation of sorts and I'm certain it can be improved. I tend to avoid the mouse for everything except menus and view selection, so I deal with by not using it.

[Electron]

What is not supported that you wish to use (other than EM/CM)?

I didn't look back at the specifics....but I remember purchasing a couple analog cards that weren't supported?  There were similiar alternatives that worked.  I just think all the analog, and discrete I/O cards should be supported if they are not already.

Ironically, the reason we chose not to support the EM/CM was precisely related to your first point. There are too many limitations with EM/CM in performance and supported modules. After discussions with the product manager at ADC, the decision was made to not support. Knowing that people would need to expand systems, however, we have always planned to support I/O expansion through the built-in Ethernet port. Which...

...as of version 1.1, to be released in the next couple of weeks, you will have fully native support for up to 16 slave devices. Slaves can be H2-EBC100, T1H-EBC100, and GS-EDRV100. The entire thing is very clean, high performance, and all associated I/O looks exactly like modules in the local rack...including CTRIO/2 support in both 205 and Terminator racks.

I didn't realize the advantages of the EBC until now...which at the time that I did my last project, I dont think these advantages were fullfilled.  At that time I was using the EBC, I still had to keep my counters, serial comms, and analogs in the base, and then I was just annoyed with the I/O addressing for the remote racks.  Looks like going down the road with the EBC is way better, considering that you are streamlining the addressing, and expanding the types of cards for remote racks.  I very often run out of base I/O slots; to be able to put counters, analogs, and maybe some comm cards wherever I want would be extremely benificial to me.

I won't argue or debate this, except to say that Do-more is, cool new features notwithstanding, a conventional PLC with a conventional PLC view of memory. Our efforts to expand the more tag-centric features tend to get us verbal abuse from those who don't like them. That said, we do have plans to create one or more new views that should be more appropriate for tag-centric people, and we will certainly consider your feedback when we spec them.

I like using the nicknames with the Do-More software, it works well for me writting code and finding what variable I am trying to reference as I write the code.  I just wish that the X-ref would allow for organization by the nickname alphabetically.  Right now, the quickest way for me to find the X-refs for a specific variable, is place a temp operator in the code, type in the nickname so I can highlight it and get the x-ref to load it.  Then I delete the temp operator. Alternatively, I also reference external Excel/Access tracking documents. Neither would be required if I could organize my x-refs by nickname.

[BobO]

What is not supported that you wish to use (other than EM/CM)?

I didn't look back at the specifics....but I remember purchasing a couple analog cards that weren't supported?  There were similiar alternatives that worked.  I just think all the analog, and discrete I/O cards should be supported if they are not already.

Well...I agree. And as far as I am aware, we support all discrete and analog I/O, and have from launch. Do you know where you heard otherwise?

Ironically, the reason we chose not to support the EM/CM was precisely related to your first point. There are too many limitations with EM/CM in performance and supported modules. After discussions with the product manager at ADC, the decision was made to not support. Knowing that people would need to expand systems, however, we have always planned to support I/O expansion through the built-in Ethernet port. Which...

...as of version 1.1, to be released in the next couple of weeks, you will have fully native support for up to 16 slave devices. Slaves can be H2-EBC100, T1H-EBC100, and GS-EDRV100. The entire thing is very clean, high performance, and all associated I/O looks exactly like modules in the local rack...including CTRIO/2 support in both 205 and Terminator racks.

I didn't realize the advantages of the EBC until now...which at the time that I did my last project, I dont think these advantages were fullfilled.  At that time I was using the EBC, I still had to keep my counters, serial comms, and analogs in the base, and then I was just annoyed with the I/O addressing for the remote racks.  Looks like going down the road with the EBC is way better, considering that you are streamlining the addressing, and expanding the types of cards for remote racks.  I very often run out of base I/O slots; to be able to put counters, analogs, and maybe some comm cards wherever I want would be extremely benificial to me.

For 1.1, all discrete, analog, and CTRIOs are fully supported in Ethernet bases and appear as normal local I/O in the map. We do not support ECOM100, ERM100, or SERIO in expansion bases, due in part to the fact that taking as many as 8 hoses and aggregating them into 1 hose of the same bandwidth is functionally impossible...but that really doesn't begin to describe the real level of complexity. Trust me when I say it gets real ugly real fast. But hopefully full native I/O support will satisfy the need.

I won't argue or debate this, except to say that Do-more is, cool new features notwithstanding, a conventional PLC with a conventional PLC view of memory. Our efforts to expand the more tag-centric features tend to get us verbal abuse from those who don't like them. That said, we do have plans to create one or more new views that should be more appropriate for tag-centric people, and we will certainly consider your feedback when we spec them.

I like using the nicknames with the Do-More software, it works well for me writting code and finding what variable I am trying to reference as I write the code.  I just wish that the X-ref would allow for organization by the nickname alphabetically.  Right now, the quickest way for me to find the X-refs for a specific variable, is place a temp operator in the code, type in the nickname so I can highlight it and get the x-ref to load it.  Then I delete the temp operator. Alternatively, I also reference external Excel/Access tracking documents. Neither would be required if I could organize my x-refs by nickname.

Then you should be pleased to know that we are working on adding sort order to both the documentation and xref views. Already have it working for docs, porting to xref now.