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

[BobO]

Is there plans for things like DeviceNet scanners for the Do-More? I could then get rid of a few CompactLogix PLCs using DeviceNet for all I/O that came in on some equipment we bought. I'm fixing to have to make some major changes to the programs and be a great time to can them

Sorry, no immediate plans. For the next bit, we will be adding the features...lots of good stuff coming, and then adding new platforms. Once we are to a reasonable feature set on a good range of hardware, we'd like to start looking at enhancing comms and see if we can go after some more competitive jobs.

[Controls Guy]

Programs are continuous when running, so edge behavior is just like $Main...which is in fact just a program that we start automatically and don't let terminate. Tasks and edges can work too, but tasks don't have to be continuous and can cause all manner of confusion when they are not. This is why the program check will warn you in certain cases.

Well, so far my choice between using programs vs. tasks is usually guided by the termination style and the nature of what it’s doing.  I’m inclined to want to use the word “task” here to describe the job for the code block, but that would be confusing, so I’ll call it a Thing To Do (TTD).  If it’s finite in scope, the completion condition is internal to the TTD, and I’d like to launch it in a fire-and-forget mode, then the self-terminating nature of programs seems like a good fit.  If it’s some continuous but low priority TTD like scaling analog inputs or something, time slicing in other words, then a periodic yielding task seems to be a good fit (yielding continuous program would work here too).  Feel free to revise your previous attitude that I've grasped the program vs. task concept.  

So I do end up using programs on TTD’s that are recurring but not periodic nor continuous low-priority.  "When situation X occurs, fire program Y."  So then when I talk about edges, one shots, etc., as they’re perceived in programs I’m not talking about how they work during one long or continuous operation (like $Main works), but how they span the first scans of multiple invocations.

You could come up with several mental models of how this might be implemented.

• VLS:  Very long scan.  The code will react as if it’s being executed synchronously with the “main” block of ladder but just with a very long scan time, seconds even.
• JMP:  Somewhat like a DL-Classic subroutine, or more properly, like a chunk of ladder after the end of the rest of the ladder (because they don’t branch immediately), enabled with a bit and a JMP, and you’re setting the bit in the regular continuous portion of the ladder.  Only SETting it, though, and the code block must RST it, even if it executes on several scans before doing so.  (A task would be the same, except the enabling coil is an OUT, and disabling is the inverse condition of enabling and handled at the same location, rather than in a pitch/catch fashion like programs.)  Edges will only be detected if it’s an edge on that particular scan of the main program.
• PTR:  The same things that would generate an edge in $Main subsequent to a Program-to-Run transition will generate an edge on the first scan of a program.  IOW, the code block will run like A $Main but not with any reference to THE $Main.

My initial instinct before experimenting was to assume the PTR model and for the most part that does turn out to be the best model.  Here’s the summary of what I learned by trial and error and observation.

• Timers reset on first scan (which isn’t bad, but slightly weird because timer ACCs are now retentive in $Main unless you make them non-retentive or enable them with STRN ST0, so this mimics DL-Classic PTR behavior but not Do-More $Main PTR).  
• One shots contacts, both bit and inline, are triggered on first scan, even if the event occurred many $Main scans ago.
• System bits (STx's) are interpreted as they would be in $Main at that same instant (because it’s a reference to a literal CPU memory location, so how could they not?).  For example, a rung enabled with ST7 in a program written to execute once and then terminate, neither always works nor always not, implying that it’s ST7 exactly as would be seen by $Main during the same scan.  Same with ST0.
• Edge triggered instructions, at least sometimes, are triggered on each execution of a program, even if enabled with STR ST1.  (This is weird because I had some edge triggered instructions in a program that appeared correct but wouldn’t work in ways that looked like edge triggering issues.   I moved the rung to $Main verbatim at ADC’s suggestion and it worked fine. [shrug])

My reason for posting is as a guide to other DM newbies, and so you can correct any misconceptions, so correct away!

[BobO]

Well, so far my choice between using programs vs. tasks is usually guided by the termination style and the nature of what it’s doing.  I’m inclined to want to use the word “task” here to describe the job for the code block, but that would be confusing, so I’ll call it a Thing To Do (TTD).  If it’s finite in scope, the completion condition is internal to the TTD, and I’d like to launch it in a fire-and-forget mode, then the self-terminating nature of programs seems like a good fit.  If it’s some continuous but low priority TTD like scaling analog inputs or something, time slicing in other words, then a periodic yielding task seems to be a good fit (yielding continuous program would work here too).  Feel free to revise your previous attitude that I've grasped the program vs. task concept.  

No, that about sums it up.

So I do end up using programs on TTD’s that are recurring but not periodic nor continuous low-priority.  "When situation X occurs, fire program Y."  So then when I talk about edges, one shots, etc., as they’re perceived in programs I’m not talking about how they work during one long or continuous operation (like $Main works), but how they span the first scans of multiple invocations.

You could come up with several mental models of how this might be implemented.

• VLS:  Very long scan.  The code will react as if it’s being executed synchronously with the “main” block of ladder but just with a very long scan time, seconds even.
• JMP:  Somewhat like a DL-Classic subroutine, or more properly, like a chunk of ladder after the end of the rest of the ladder (because they don’t branch immediately), enabled with a bit and a JMP, and you’re setting the bit in the regular continuous portion of the ladder.  Only SETting it, though, and the code block must RST it, even if it executes on several scans before doing so.  (A task would be the same, except the enabling coil is an OUT, and disabling is the inverse condition of enabling and handled at the same location, rather than in a pitch/catch fashion like programs.)  Edges will only be detected if it’s an edge on that particular scan of the main program.
• PTR:  The same things that would generate an edge in $Main subsequent to a Program-to-Run transition will generate an edge on the first scan of a program.  IOW, the code block will run like A $Main but not with any reference to THE $Main.

I think PTR is the best model, but maybe it would be helpful if I give you a glimpse under the covers. Every edge has a hidden bit in the image register that contains the prior state of the associated bit, and is initialized to zero by the Do-more engine. Simply put, an edge is defined by the prior state being low and the current state being high, as viewed by the instruction itself. The other key point is that edge bits are re-initialized to zero any time instruction block or stage termination is run.

• Timers reset on first scan (which isn’t bad, but slightly weird because timer ACCs are now retentive in $Main unless you make them non-retentive or enable them with STRN ST0, so this mimics DL-Classic PTR behavior but not Do-More $Main PTR).  

They actually reset on termination, the first scan after the block is 'done'. We have a case to add an option to ATMR to not reset on termination. Sounds like that would fit you.

• One shots contacts, both bit and inline, are triggered on first scan, even if the event occurred many $Main scans ago.

Yes. The only exception is counter inputs.

• System bits (STx's) are interpreted as they would be in $Main at that same instant (because it’s a reference to a literal CPU memory location, so how could they not?).  For example, a rung enabled with ST7 in a program written to execute once and then terminate, neither always works nor always not, implying that it’s ST7 exactly as would be seen by $Main during the same scan.  Same with ST0.

Yes, the ST locations are global image register managed by the system, independently of the task or program they are referenced from. They are not timers, per se, but can be used to control time based behaviors. For timed operations within a program, use a timer. In using a timer in this way, the need for termination upon completion starts to make sense.

• Edge triggered instructions, at least sometimes, are triggered on each execution of a program, even if enabled with STR ST1.  (This is weird because I had some edge triggered instructions in a program that appeared correct but wouldn’t work in ways that looked like edge triggering issues.   I moved the rung to $Main verbatim at ADC’s suggestion and it worked fine. [shrug])

There was a bug in 1.0 in tasks, where a completion and re-enabling of a one-shot task within the same scan would not run termination, resulting in busted edges. It's fixed for 1.1. Other than that, edges should work as expected and will always fire on each RUN or ENTASK, and reset on the termination scan after each completion.

[DLTimmons]

I found a soluntion for the DeviceNet connection issue, Turck has a BL67-GW-EN-DN a modbus TCP to DeviceNet Gateway I found one on line for $502.74. They make some other gateway too, all IP67 Rated.

[Controls Guy]

I didn't know Turck made gateways.  Good to know.  And $500 a pop is a steal.  Most of the Prosoft stuff, for example is in the $1500 and up range.

[BobO]

$1500? I'm in the wrong business...

[Controls Guy]

Yeah, I know. Kinda hard to part with $[3 PLCs] for a protocol gateway.  And $1500 is nothing; I think one I priced recently was like $2800 or something.  (Compact Logix in-rack Modbus TCP master.  Course any module that's AB in-rack, a lot of the cost comes from the AB vig.)

[CReese]

Thank you so much for the Datainfo blocks and parameterizing everything. I have just transformed hundreds of pages of code into 1.5 pages and a handful of memory blocks.

[franji1]

Thank you so much for the Datainfo blocks and parameterizing everything. I have just transformed hundreds of pages of code into 1.5 pages and a handful of memory blocks.

Sweet!

[plcnut]

Is there a way to reserve a chunk of memory so that it won't show up in "the next available element" of the nickname assigner?
Example: SET: C[V0] where V0 could be 0 through 9. I can use MEMCLEAR or INIT for this range and it will then show up as used in the xref usage mode, but how do I eliminate it from showing up in the nickname assigner?

[Controls Guy]

Some "auxiliary" windows such as XRef default to a horizontal docked position.  I tend not to like this as it steals screen real estate from ladder.  Now the window can be undocked and/or dragged over and docked on the side like DirectSoft (which always felt like an annoying compromise anyway vs. just allowing them all to be full screen), but the new XRef view has a lot more information, so it doesn't act like a very good citizen in a tall narrow view.

The most important columns the way I work/think are the first and fifth, followed by the fourth, followed by the third.  So I'd like to be able to rearrange the column order, stretch the width (preferably all the way to zero), and/or hide and unhide specific columns.  It seems almost necessary to make it useful in a vertical format at a reasonable percentage of screen width, but none of those are options.  I suspect it was made draggable/dockable, but none of the developers uses it on the side. (Or perhaps has a really wide monitor).

CORRECTION:  You can stretch the column widths, but the already-too-wide default width is the minimum for many of the columns.

So, feature request:  Configurable columns in XRef.  Some combination of draggable order, width adjustable to much smaller values or zero, and hide/unhide.

BTW, the filter buttons for IN, OUT, IN/OUT:  very cool!

[BobO]

Is there a way to reserve a chunk of memory so that it won't show up in "the next available element" of the nickname assigner?
Example: SET: C[V0] where V0 could be 0 through 9. I can use MEMCLEAR or INIT for this range and it will then show up as used in the xref usage mode, but how do I eliminate it from showing up in the nickname assigner?

There's not a way to do it, but I understand the need. For now, I would probably create different blocks for things I intended to treat that way.

[plcnut]

Is there a way to reserve a chunk of memory so that it won't show up in "the next available element" of the nickname assigner?
Example: SET: C[V0] where V0 could be 0 through 9. I can use MEMCLEAR or INIT for this range and it will then show up as used in the xref usage mode, but how do I eliminate it from showing up in the nickname assigner?

There's not a way to do it, but I understand the need. For now, I would probably create different blocks for things I intended to treat that way.

I guess I could just give them nicknames, that would get them out of the list

[BobO]

Some "auxiliary" windows such as XRef default to a horizontal docked position.  I tend not to like this as it steals screen real estate from ladder.  Now the window can be undocked and/or dragged over and docked on the side like DirectSoft (which always felt like an annoying compromise anyway vs. just allowing them all to be full screen), but the new XRef view has a lot more information, so it doesn't act like a very good citizen in a tall narrow view.

The most important columns the way I work/think are the first and fifth, followed by the fourth, followed by the third.  So I'd like to be able to rearrange the column order, stretch the width (preferably all the way to zero), and/or hide and unhide specific columns.  It seems almost necessary to make it useful in a vertical format at a reasonable percentage of screen width, but none of those are options.  I suspect it was made draggable/dockable, but none of the developers uses it on the side. (Or perhaps has a really wide monitor).

CORRECTION:  You can stretch the column widths, but the already-too-wide default width is the minimum for many of the columns.

So, feature request:  Configurable columns in XRef.  Some combination of draggable order, width adjustable to much smaller values or zero, and hide/unhide.

BTW, the filter buttons for IN, OUT, IN/OUT:  very cool!

We have plans to create what we are calling 'super view' that would be a fully configurable Xref/Doc/Data/Etc view. Not sure of the schedule for it, but we feel that may be a better plan than trying to fix all of the existing views. Improving the configurability of the Xref view probably wouldn't be too hard though, so we might look at that for a future release.

[BobO]

Is there a way to reserve a chunk of memory so that it won't show up in "the next available element" of the nickname assigner?
Example: SET: C[V0] where V0 could be 0 through 9. I can use MEMCLEAR or INIT for this range and it will then show up as used in the xref usage mode, but how do I eliminate it from showing up in the nickname assigner?

There's not a way to do it, but I understand the need. For now, I would probably create different blocks for things I intended to treat that way.

I guess I could just give them nicknames, that would get them out of the list

Yep...that'd work to. Sometimes the simplest answers are the best.