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

[BobO]

The Do-More would also be required to control the pressure system (PID proportional valves, on/off valves, etc).  Data acquisition would be sending analog signals from pressure transducers, flow meters for trending and chart recording.

...and this part would be no sweat too.

[rlp122]

BobO,

Do you believe that the Do-More would be capable of data acquisition?  Say system would have at most eight analog inputs and trying to write data at a max of 100Hz, most typical scenerios would be 10Hz.  I was thinking a direct connections with InduSoft Web Studio SCADA and collection to central SQL type database.

Thanks!

Pretty sure that the physical limitations of the analog modules would prevent 100Hz.  You could do it, but you wouldn't get new data for every log.

[BobO]

Pretty sure that the physical limitations of the analog modules would prevent 100Hz.  You could do it, but you wouldn't get new data for every log.

Yeah, I'd say you are right. There is nothing that would prevent it from Do-more's perspective (CPU speed, backplane throughput, etc), but the analog may not source it that fast.

<...time passes...>

I just did a very quick test, using a delta contact with an analog input feeding a FREQCNT instruction to compute the rate that data changes. The analog input is fed by a resistor voltage divider and other than noise is not changing, so I am probably not getting the full number of conversions. With that test, I am seeing around 45-50Hz. It also bears mention that the analog card is in an EBC rack that I am talking to with the new Ethernet Expansion I/O feature of the DM1E, which is updating at about 5ms....with analog and 4 CTRIO modules in the base. I'm quite pleased with the performance.

<...more time passes...>

OK...admittedly I'm just showing off now...but with a delta contact, FREQTMR instruction, a math box to round the frequency, and an increment instruction, I created a histogram to determine where the bulk of the updates were occurring. The result is clusters at 33Hz, 45Hz, and 66Hz, with the bulk of those at 45Hz. Yes, actually, I do think MacGuyver would be proud.

[Controls Guy]

Yes, actually, I do think MacGuyver would be proud.

Only if you used a toothbrush and some thermite made solely from stuff you found under the bathroom sink! 

[Maxwell]

I just finished my first real job with the Do-more and I'm thrilled with it.  One area where I did encounter problems is working with the C-more.  One thing that someone else commented on is the fact that the c-more can't see user defined memory blocks.  One other problem that I haven't seen anyone comment on is the fact that the c-more gets really flaky when displaying UDT structure members.  They display correctly in some locations, but a direct copy of the display object will show incorrect values in a different screen.  I reported this to Automation Direct and they ended up suggesting that I write the UDT structure members to V locations and then point the c-more to those memory locations instead.

Just out of curiosity, any chance that Host will decide to design the next generation c-more?  I'd love to see you bring the same inovation and fresh attitude to the design of a HMI that interfaces natively with Automation Direct PLC's, that you brought to the design of the Do-more.

[BobO]

I just finished my first real job with the Do-more and I'm thrilled with it.  One area where I did encounter problems is working with the C-more.  One thing that someone else commented on is the fact that the c-more can't see user defined memory blocks.  One other problem that I haven't seen anyone comment on is the fact that the c-more gets really flaky when displaying UDT structure members.  They display correctly in some locations, but a direct copy of the display object will show incorrect values in a different screen.  I reported this to Automation Direct and they ended up suggesting that I write the UDT structure members to V locations and then point the c-more to those memory locations instead.

Just out of curiosity, any chance that Host will decide to design the next generation c-more?  I'd love to see you bring the same inovation and fresh attitude to the design of a HMI that interfaces natively with Automation Direct PLC's, that you brought to the design of the Do-more.

Glad to hear that Do-more did more! We're busy adding features for 1.1, after which it will Do-even-more!

As for C-more, ideally ADC will continue to work with Koyo to bring the Do-more driver up to standard. At some point in the not too distant future we will be developing a specification to allow other panel manufacturers to access Do-more natively. A little competition has a way of bring out the innovative spirit, so we'll see what happens.

[Maxwell]

Glad to hear that Do-more did more! We're busy adding features for 1.1, after which it will Do-even-more!

Great!  When's it coming out?  Will the "Small File System" you mentioned in your message on  February 28, 2013, @ 11:09:58 am be part of 1.1?

On a related note, two things that would be nice features to get at some point in the future are:

• The ability to copy and paste part of a rung into another rung.  Several times when debugging a program I've ended up developing some complicated logic arrangement to handle some unusual situation that comes up during development testing and I end up wanting to add that logic into existing rungs in multiple stages or code locations.
• A JMPNow command that jumps immediately without processing the rest of the rungs in the stage.

Of the two, my highest priority would be the JMPNow command.  I don't want to replace the current jump command, I'd just like this as an additional option.  Obviously there are a couple of ways to avoid running the remaining rungs without a command like this, but it would make coding faster and more elegant if it were available.

[BobO]

The big 1.1 feature is built-in Ethernet expansion I/O, with initial support for H2-EBC100, T1H-EBC100, and GS-EDRV100. No file system yet, but that shouldn't be too much longer.

The jump now instruction wouldn't be too difficult and I can see how it would be useful, although my gut reaction is that you may be doing too much in the stage. A handy workaround is to use the stage bit as a condition, since the JMP immediately clears the it even though it doesn't immediately jump out of the code.

The editor is a bit harder, but we are definitely wanting to do some work there too. Key thing is to deal with getting the features in Do-more that are limiting us (like no expansion I/O). Once we get those out of the way, we can start looking at some of the other 'nice to haves'.

[ATU]

my gut reaction is that you may be doing too much in the stage.

I had the same thought. You've got a ton of stages to work with, use them.  I try to limit looking for 1 condition in each stage.  If your process dictates that you are monitoring for multiple simultaneous events, then have parallel threads in either stages, tasks or programs.   

[franji1]

JMPNOW could not necessarily really Jump to THAT stage, but to the NEXT stage in ladder memory.  We could make it Jump (literally) to THAT stage also, but it would break the general flow of the ladder logic.  Other entire stages logic would be SKIPPED when jumping "forward" - THIS IS BAD.  Or, if moving backwards in program memory, would generate a LOOP, which is ALSO bad.  Literally jumping backwards would include executing OTHER stages TWICE in the SAME SCAN (Timers would not time correctly, et. al.).

I am going to guess that you really want it to jump to THAT stage, but that would require YOU to ENSURE that THAT stage is the "next" one in memory, which is a non-obvious burden/responsibility on the user.  We could require Do-more to make sure the JMPNOW stage is the NEXT one.  I would guess that would be the only way to make it work as expected.  That would also imply that you could only JMPNOW to Stage 10 from JUST ONE STAGE, the one preceding it, implying that S5 and S6 could NOT BOTH JMPNOW to Stage 10.

This construct I think implies you are probably doing too much within your stages (see other comments), cuz the side effects of a literal JMPNOW will be worse than any logic you think you need to skip in your current implementation.

[Maxwell]

JMPNOW could not necessarily really Jump to THAT stage, but to the NEXT stage in ladder memory.  We could make it Jump (literally) to THAT stage also, but it would break the general flow of the ladder logic.  Other entire stages logic would be SKIPPED when jumping "forward" - THIS IS BAD.  Or, if moving backwards in program memory, would generate a LOOP, which is ALSO bad.  Literally jumping backwards would include executing OTHER stages TWICE in the SAME SCAN (Timers would not time correctly, et. al.).

I am going to guess that you really want it to jump to THAT stage, but that would require YOU to ENSURE that THAT stage is the "next" one in memory, which is a non-obvious burden/responsibility on the user.  We could require Do-more to make sure the JMPNOW stage is the NEXT one.  I would guess that would be the only way to make it work as expected.  That would also imply that you could only JMPNOW to Stage 10 from JUST ONE STAGE, the one preceding it, implying that S5 and S6 could NOT BOTH JMPNOW to Stage 10.

This construct I think implies you are probably doing too much within your stages (see other comments), cuz the side effects of a literal JMPNOW will be worse than any logic you think you need to skip in your current implementation.

I guess I didn't explain my idea very clearly.  It wasn't that I wanted to jump instantly to other parts of the ladder logic.  What I was thinking is that there would be times where it would be nice to automatically disable the rest of the logic in the stage I'm running once I get to a decision point that results int a jmp command.  Most of the time, I run through a stage and jump at the end.  Occasionally; however, I'll get a stage which contains several interconnected decisions.  The last time this happened, I was in a stage where I was preparing to run a process and depending on a number of different factors, I needed to either jmp into the first stage of running the process, jmp to an alternative version of the process, exit that mode entirely, or skip that process stage entirely and start the next process down the line.  My previous programming experience before PLC's was FORTRAN 77 (years ago) and I guess I tend to think in IF,THEN,ELSE Blocks.

As I said before, disabling the remaining few rungs in a stage usually isn't needed.  In those cases in the future where I do want to skip the remaining rungs, I'll follow BobO's advice and use the stage bit as a condition. (I wasn't thinking about the fact that the stage bit turns off at the instant the jmp command is encountered.)

[franji1]

We can definitely help you there.

When you JMP, the stage you are in has ITS bit turned OFF.  Hence, you can easily utlize this fact when branching (like a C switch statement or IF ELSE IF ELSE IF ELSE IF... type construct.

If you are in Stage 10, use S10 contact as a permissive of the other JMP branch conditions

Code: [Select]

[SG S10]
...
 S10    X0        S20
-] [---] [------( JMP )

 S10    X5        S21
-] [---] [------( JMP )

 S10    X7        S22
-] [---] [------( JMP )

 S10    X2        S23
-] [---] [------( JMP )


You might also look at the JMPI (Indexed Jump) if you have a "state" value that you can easily index 0..n-1 to jump to n different stages starting at Sj to Sj+n-1, i.e. index value V20 equal to 0..9 with JMPI S100 would jump to Stage S100 thru 109 based off the value of V20 (note that the last stage in the series is actually a final "else" or "exception" stage when V20 is out of range, so any value other than 0..8 would JMP to Stage S109.)

[Maxwell]

If you are in Stage 10, use S10 contact as a permissive of the other JMP branch conditions

Code: [Select]

[SG S10]
...
 S10    X0        S20
-] [---] [------( JMP )

 S10    X5        S21
-] [---] [------( JMP )

 S10    X7        S22
-] [---] [------( JMP )

 S10    X2        S23
-] [---] [------( JMP )



Your code example is exactly what I'll probably do in the future.  I knew that the stage bit turned off when you jumped from the stage and I use that fact in other locations when I need to make decisions based on what stage is or is not running.  Before BobO mentioned it; however, I wasn't making the mental connection that the stage bit turned off at the instant that the jmp command was encountered.  I was just assuming the the bit turned off when you actually finished the stage.  In hind sight, the way it actually works makes sense, but I just didn't make the connection. 

On a side note, these tips and suggestions that I've been picking up on this forum have been very helpful.  I don't have ready access to anyone else at work who uses PLC's with ladder logic programming, and so this forum has been a real blessing as a source of information.

[franji1]

I don't have ready access to anyone else at work who uses PLC's with ladder logic programming, and so this forum has been a real blessing as a source of information.

Here are some others:

• Designer's Start Page: click on any of the 8 topics to browse various topics.
  
• Designer's Tip of the Day: short tid bits
  
• Designer's Help System: there is good information throughout the topics that provide interesting details about various views, tools, utilities in Do-more
• http://www.do-morePLC.com : Lots of articles and free videos to help you learn about Do-more
  
• http://www.interconnectingautomation.com : I think ADC is still providing FREE 30 day's worth of Do-more training for every CPU.  There's advanced training there also.

And of course, this forum, which is actually all of various customers and users out there that provide helpful answers, tips, ideas, issues, etc.

[BobO]

On a side note, these tips and suggestions that I've been picking up on this forum have been very helpful.  I don't have ready access to anyone else at work who uses PLC's with ladder logic programming, and so this forum has been a real blessing as a source of information.

Glad to hear it! We're happy to help, so please feel free to ask anything. We're obviously biased, but we feel that Do-more is far more powerful that most are aware of. As we answer these questions we put 'best practices' out for others to read, and we aid the questioner in learning to use Do-more more fully. In time there will be a bunch of folks out there that know what Do-more can really do!