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

[ATU]

Probably depends on what's in the rack. Remember the 405 had a slew of specialty modules, some dependent on system memory registers.

[franji1]

So swap your 405 CPU for an EBC and run the rack as remote to a DM1E with no I/O.  (Hosties, this is doable, yes?)

As Do-more Ethernet I/O, no.  There is no EBC100 on 405.  Do-more only natively supports H2-EBC100, T1H-EBC100, and GS-EDRV100's.  None of the old EBC (non-100) models are supported natively by Do-more.

You could make existing H4 bases work using the legacy H2-ERM100 module in a 205 Do-more rack, and swapping out the 450 with the H4-EBC, but it won't be native Do-more I/O.  It would show up as DLX, DLY, DLC, and/or DLV.  You must also use NetEdit to configure all your 405 I/O, none of which would be stored as part of the Do-more project file.

[Controls Guy]

As Do-more Ethernet I/O, no.  There is no EBC100 on 405.  Do-more only natively supports H2-EBC100, T1H-EBC100, and GS-EDRV100's.  None of the old EBC (non-100) models are supported natively by Do-more.

Oh OK.  So many EBC's are supported natively, I assumed they all would be.  The serial port on the 405 will also do Modbus RTU, so that would be another option.  I've used 405's (and 205's) as remote Modbus I/O that way before.

[BobO]

So many EBC's are supported natively, I assumed they all would be.

Do-more uses a special mode with some advanced features. It simply wasn't practical to add support in the original EBC.

[Controls Guy]

Oh, so you're saying you modified the EBC's now compatible with Do-More to make them so?

Oh, and the H4-ECOM100's also support Modbus/TCP.

[BobO]

Oh, so you're saying you modified the EBC's now compatible with Do-More to make them so?

Yes.

[Mike Nash]

I'm working on a project that includes a GOTO instruction. Everything is in $Main for this one. But on Save or Check I get 45 messages like:

[Message]   $Main@1325   M331 Asynchronous instruction TMR used in code-block with 1 yielding instruction (GOTO at @873)

But I only have a few timers between the GOTO and LABEL and it is telling me about every timer in the program, even those with no coils or contacts within the range.

I know the ones between the GOTO and LABEL will probably always be a message source, but with 45 of them (and indicating position, not the rung - blech), it is kind of anti-helpful.

So what would be the best way of implementing this conditionally skipped code anyway? This is a retrofit project and we don't want to reinvent the wheel on this one, just translate and go - hence all in $Main.

[BobO]

Next version will allow you to control what program check rules are applied globally and I think possibly on an instance basis.

What he's complaining about is that timers may not work correctly if not executed every scan. Any yielding instruction (GOTO is yielding) can result in the program not executing the entire block every scan and can result in timers losing time. In $Main that isn't really a problem due to the default timeslice being 65535 (unyielding), but we can't really know that at program check time, so we complain.

How to handle? Depends on what the conditional code is doing. If it is a part of some computational code and needs to be executed inline, I'd use the GOTO for now, and a FUNCTION or SUBROUTINE when we get them implemented in the future. If the code is just a chunk of code that is enabled or disabled as part of a mode, and was previously implemented in an MLS/MLR section, I'd move it to a TASK block.

[Controls Guy]

How hard would it be to make timers initial clock time plus duration based, rather than scan time accumulation based?  It seems like there's a couple advantages to that approach and I can't really see a downside (accuracy being one advantage, this issue being another).

[ADC Product Engineer]

The RTC isn't nearly as stable as the scan timer for starters.  Plus you would be adding a fair amount of complexity to a pretty simple system as it is today.  I think there would be quite a bit of complaint over the accuracy of the timing if it were to be done that way and timing accuracy is one thing PLC's are judged on.

[Controls Guy]

Hmmm....interesting (and somewhat surprising).  I'd have thought that the two were equally accurate, and if told that there was a difference, I'd have assumed the RTC was the more accurate.  The other reason I assumed that approach would have improved accuracy was one single rounding error at the end of the time, vs. one per scan so that the error is non-cumulative.  Live and learn, I guess!   

[BobO]

The RTC isn't nearly as stable as the scan timer for starters.  Plus you would be adding a fair amount of complexity to a pretty simple system as it is today.  I think there would be quite a bit of complaint over the accuracy of the timing if it were to be done that way and timing accuracy is one thing PLC's are judged on.

It wouldn't use the RTC, and actually couldn't, since the RTC is only good to 1 second.

[BobO]

Hmmm....interesting (and somewhat surprising).  I'd have thought that the two were equally accurate, and if told that there was a difference, I'd have assumed the RTC was the more accurate.  The other reason I assumed that approach would have improved accuracy was one single rounding error at the end of the time, vs. one per scan so that the error is non-cumulative.  Live and learn, I guess!   

The answer to your OP is that it could be done, but would require 50% more image register memory (3 DWORDs instead of 2) since you would still need to store the elapsed time for status displays. The computational hit would be essentially the same.

There is no cumulative error either way, assuming the timer instruction is run exactly once per scan, because there is no rounding in integer math.

At this point, it is mostly moot, since changing the instructions is not an option. It is pretty easy to roll your own though, if this is important to you. In the MATH box, the TICKms() function gives you access to the raw millisecond tick counter that the timer instructions are built on.

[Controls Guy]

There is no cumulative error either way, assuming the timer instruction is run exactly once per scan, because there is no rounding in integer math.

That removes the main reason I thought the other approach might be better.  Another reason would be timing continuity while the PLC is powered off, but you can still do that manually using the RTC.

At this point, it is mostly moot, since changing the instructions is not an option. It is pretty easy to roll your own though, if this is important to you. In the MATH box, the TICKms() function gives you access to the raw millisecond tick counter that the timer instructions are built on.

I actually don't.  My post was in response to what the other guy was asking about, which also kind of tickled some ideas I had had about the timing method.

[Controls Guy]

Does DMD or the printer driver handle pagination?  Do-More must at least be aware of it, even if the driver's doing it because it can preview.  Anyhow, check this image; this follows two NOPs at the end of a program.  One of those edge cases that have to be checked for and corrected in real time.  Personally I don't mind if you omit the NOPs that print at the end of each code block as well.