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

[BobO]

Historically, 232 would have been semi-preferred for a programming port over 485, but I think anymore most people will program via Ethernet or USB, and even for serial, nobody has 232 ports anymore anyways, so they're going to need a USB-232 converter, and those are just as readily available and just as cheap in USB-485.

Where the 485 would be missed is in multidrop Modbus mastering.  I talk to drives a lot via 485 Modbus and will miss it if I don't have it.  But yeah, we can easily convert to 485 outside the PLC, and there's so many other improvements vs. the Koyo product that this is hardly more than an annoyance.

Sounds like you are building a case to do it. I'm certain that we don't have space to put the customary 5 pin terminal, so we'd have to stick with the RJ12. Not sure if there is a potential for it, but just imagining the screams of agony when that resulted in something getting broken...

[Controls Guy]

I've used 250's as dumb Modbus I/O on 485 as well.  Could be done with Ethernet on a Do-More I guess, though that doesn't work as well in a straight line topology, which is what I had when I used to do that.  Very long machines with all power and I/O wiring contained within each section, and just an E-Stop and comms buss down the length.

[UPDATE:  On further reflection, this scenario is irrelevant to the 232 vs 485 discussion.  If I wanted to use 205 racks as remote I/O on 485, I'd just use a 250 like I used to.  It's cheaper than a Do-More and since there's no or negligible ladder running, there's no advantage to using a DM anyway.]

[Controls Guy]

Sounds like you are building a case to do it. I'm certain that we don't have space to put the customary 5 pin terminal, so we'd have to stick with the RJ12.

Yeah, I guess my one vote is for 485 over 232 if I have to pick one over the other, for the reasons stated.  (need the 485 for multidrop Modbus, other std ports available for programming in the DM, nobody has 232 built-in anymore anyway...)

Not sure if there is a potential for it, but just imagining the screams of agony when that resulted in something getting broken...

No doubt.  Are the signal levels sufficiently similar that nothing will get fried if you plug in a cable and it's 485 on one end and 232 on the other?

You might also consider some other modular connector (not RJ-45 obviously) to differentiate.

[BobO]

There are 3 basic uses for the CPU's serial port: 1) programming, 2) HMI slave comms, 3) external device master comms. Historically programming was the primary, although USB and Ethernet have greatly reduced that. So that leaves HMIs and devices. Guess what C-more Micro's port is...yes...RS232. Guess what disproportionately connects to that port...yes...C-more Micros. I'm sure there are some that would use the RS485 for the reasons that were stated, but the bulk of it is still RS232.

[Controls Guy]

There are 3 basic uses for the CPU's serial port: 1) programming, 2) HMI slave comms, 3) external device master comms. Historically programming was the primary, although USB and Ethernet have greatly reduced that. So that leaves HMIs and devices. Guess what C-more Micro's port is...yes...RS232. Guess what disproportionately connects to that port...yes...C-more Micros. I'm sure there are some that would use the RS485 for the reasons that were stated, but the bulk of it is still RS232.

Ooh, good point. I never really warmed up to C-More's in general, but especially the Micros, so it takes me by surprise that they're the default MMI (just the Micros, not surprised about the C-Mores in general, but then those probably have a 485 port and sometimes Ethernet).  And yeah, that sounds like probably the telling factor in that decision.  Oh well, like I said, DM provides so many other advantages that this is a [very] minor issue and easy to work around anyway with an external converter.

[ATU]

I would much rather have RS232 on the CPU and use an isolated 485 converter, especially if you have any distance between drops.  Plus my serial analyzer works better with RS232.

[Maxwell]

With regards to your original question of our experience with the Do-More, I absolutely love it.  I don't have a lot of experience with PLC's, but I did some limited work with DL06 units a few years ago.  A decision was recently made to try doing a lot of applications in house via PLC that were previously done manually or via embedded controls developed/provided by another group.  When I started looking at PLC's to utilize, I was very happy to discover that the Do-More had come out.  From my perspective, it's a massive improvement over the DL line.  We are currently in the midst of developing our first application using the Do-More and I plan to utilize it almost exclusively.  (Maybe a PAC3000 instead for a few aggressive applications further down the road.)  I am especially happy about the move from BCD and the improvements to memory structure in general, along with the ability to organize the programming into code blocks.

I may be a little unusual in my uses, but one of the things that I would really like to see as a future capability is a very easy way to log data, errors, messages, etc... in a way that is easy for a technician/operator to read off onto a laptop as needed.  We are going to be using most of our PLC applications in remote locations and situations where there is no network capability.  As a result, I'd love to see something like the micro SD setup you often have with smart phones.  I would love to be able to install a micro SD card in a Do-More and then have the card mount in Windows Explorer when I connect a laptop to the USB programming port.  Ideally, there would be commands in the PLC to easily create files on the storage card and then write log data to those files which could then be easily accessed when a computer was connected to the USB port.  This type of storage configuration would also let me take the "Downloadable Documentation" concept even further by allowing me to store all of the documentation for the entire machine on the PLC in any software format I desired.  I could include troubleshooting procedures, operator aids, wiring schematics, etc..., and not just the PLC programming documentation.

One last feature that would be helpful for some of our applications would be the ability to have the Do-More go into a low power standby mode and then only power up to run mode when a time/date is reached or an outside event sends a wake up signal.  (We have applications where we would like to have a controller connected to a 12V battery in a field location power up and run after potentially long wait periods.)  We can continue to utilize embedded controllers, but it would be nice to use PLC's in some of these applications.  I guess I could play around with separate devices which make or break the power supply to the PLC, but it would be more elegant if the PLC had a built in sleep mode.  (I realize that this is probably not a common user request, so I understand if it doesn't make business sense to add a feature like this.)

Thanks.  Keep up the good work.

[BobO]

With regards to your original question of our experience with the Do-More, I absolutely love it.  I don't have a lot of experience with PLC's, but I did some limited work with DL06 units a few years ago.  A decision was recently made to try doing a lot of applications in house via PLC that were previously done manually or via embedded controls developed/provided by another group.  When I started looking at PLC's to utilize, I was very happy to discover that the Do-More had come out.  From my perspective, it's a massive improvement over the DL line.  We are currently in the midst of developing our first application using the Do-More and I plan to utilize it almost exclusively.  (Maybe a PAC3000 instead for a few aggressive applications further down the road.)  I am especially happy about the move from BCD and the improvements to memory structure in general, along with the ability to organize the programming into code blocks.

Thanks for the kind words. I would be interested in hearing the specifics of how you would choose between the PAC and Do-more. One of the big questions that has come up is why you would choose one over the other. Being the proud papa I am, it's pretty obvious that I would choose Do-more in every case that it would do the job, but I would love to be able to see that same decision from an unbiased user's perspective. I'm sure there are some things the PAC does better than we do, and I know their I/O counts go much higher than ours...although I/O shouldn't be an issue much longer. The Ethernet Expansion I/O feature is shaping up very nicely and will be out as quickly as we can get it tested and solid.

I may be a little unusual in my uses, but one of the things that I would really like to see as a future capability is a very easy way to log data, errors, messages, etc... in a way that is easy for a technician/operator to read off onto a laptop as needed.  We are going to be using most of our PLC applications in remote locations and situations where there is no network capability.  As a result, I'd love to see something like the micro SD setup you often have with smart phones.  I would love to be able to install a micro SD card in a Do-More and then have the card mount in Windows Explorer when I connect a laptop to the USB programming port.  Ideally, there would be commands in the PLC to easily create files on the storage card and then write log data to those files which could then be easily accessed when a computer was connected to the USB port.  This type of storage configuration would also let me take the "Downloadable Documentation" concept even further by allowing me to store all of the documentation for the entire machine on the PLC in any software format I desired.  I could include troubleshooting procedures, operator aids, wiring schematics, etc..., and not just the PLC programming documentation.

We actually developed a small file system (a few megabytes) for Do-more. It didn't make the initial release due to schedule, but it is definitely something that we will be adding in the future. I think it would be everything you want, minus the removable media.

I don't know if you know this, but you can already attach a document to the downloaded project. It's limited to 1MB, but it is in there now under 'Tools>Attach User Document...'.
 

One last feature that would be helpful for some of our applications would be the ability to have the Do-More go into a low power standby mode and then only power up to run mode when a time/date is reached or an outside event sends a wake up signal.  (We have applications where we would like to have a controller connected to a 12V battery in a field location power up and run after potentially long wait periods.)  We can continue to utilize embedded controllers, but it would be nice to use PLC's in some of these applications.  I guess I could play around with separate devices which make or break the power supply to the PLC, but it would be more elegant if the PLC had a built in sleep mode.  (I realize that this is probably not a common user request, so I understand if it doesn't make business sense to add a feature like this.)

Sounds like an interesting feature, but as you suspect, not a common one. In truth I'm not even sure how it would be approached...but it sounds *very* cool.


Thanks for the feedback!

[Controls Guy]

Maybe a PAC3000 instead for a few aggressive applications further down the road.

I know very little about the P3K's, but my image of them certainly is not as the bigger, more capable alternative to the Do-More.  Quite the opposite, in fact.

We are going to be using most of our PLC applications in remote locations and situations where there is no network capability.

You might consider radio modems.  I'm doing a project right now with ultimately multiple PLC's anywhere from a few hundred yards to about 5 miles from the HMI PC, and the radios claim they'll do up to 40 miles optimally.  Digi, 1 watt, $300 a pop.  The remote stations are totally solar powered with deep cycle batteries for storage.

[Maxwell]

I would be interested in hearing the specifics of how you would choose between the PAC and Do-more.

The only job that I was thinking about looking at the PAC for is a combination data acquisition & control application in a testing lab we have.  A vendor that did some PLC work for us a couple of years ago recommended that we look at using the PAC due to high speed and large # of inputs.  To be honest, I haven't looked at it in much detail because it will be a couple of years before we get the funding for that job.  I had planned to look into the PAC at that time and compare it vs a dedicated commercial data acquisition system combined with DL205 PLC's for the control part.  Maybe the Do-more would be the best choice?  I'll certainty look at it when we get closer to doing the job.

We actually developed a small file system (a few megabytes) for Do-more. It didn't make the initial release due to schedule, but it is definitely something that we will be adding in the future. I think it would be everything you want, minus the removable media.

I don't really care if the media is removable.  I just figured that would give the end user a way to install as much as they want for their particular application while saving the manufacturer the cost of building in the memory in every CPU whether it is needed or not.  My real desire is the ability to easily log / write to the storage area and then have it be accessed via USB without special software when I get the chance to connect a laptop to the PLC.  Maybe the file system feature you mentioned will be the ticket.

I don't know if you know this, but you can already attach a document to the downloaded project. It's limited to 1MB, but it is in there now under 'Tools>Attach User Document...'.

I saw that via your start page topics, but if I remember right, it was limited in the types of files that could be downloaded, plus the size limitation.  Is that right?

You might consider radio modems.  I'm doing a project right now with ultimately multiple PLC's anywhere from a few hundred yards to about 5 miles from the HMI PC, and the radios claim they'll do up to 40 miles optimally.  Digi, 1 watt, $300 a pop.  The remote stations are totally solar powered with deep cycle batteries for storage.

For a number of different reasons, the radio option often isn't allowed or worthwhile for many of our applications.  With regards to your application, be ready to invest some real time and effort into getting the radios to work.  We've done some work connecting field equipment via radios supplied by another group in our company.  The radio jobs seem to be very temperamental and work some times in some places, but not in others.  Our experience is also that you will not get anywhere near the range they claim and the cheap systems end up costing more in the long run that just paying the money for the more expensive systems up front.  If you're talking short ranges, and flat open locations, you have a lot fewer problems.  Long range mesh systems in hilly locations with trees are the worst situations.  I've got a researcher that I support who is looking at installing a bunch of computer controlled instruments out in the desert this fall and interfacing with them via a wireless Ethernet system.  We haven't started any field testing yet, but we were looking at a system made by Afar http://www.afar.net/wireless/ethernet-bridge/ that looks pretty good on paper.  Their support engineers have been helpful too.

[Controls Guy]

With regards to your application, be ready to invest some real time and effort into getting the radios to work.  We've done some work connecting field equipment via radios supplied by another group in our company.  The radio jobs seem to be very temperamental and work some times in some places, but not in others.  Our experience is also that you will not get anywhere near the range they claim and the cheap systems end up costing more in the long run that just paying the money for the more expensive systems up front.  If you're talking short ranges, and flat open locations, you have a lot fewer problems.  Long range mesh systems in hilly locations with trees are the worst situations.

Optimistic range ratings have been my [somwhat limited] experience too, so when possible we get substantially more rated range than what's actually needed, and test.  In this case, we tested at about 150% of the range over similar terrain (slightly rolling desert with brush) with good results at about 5' less mast height than we'll have in reality.  Additionally I'm designing the app to cache all necessary control data at the remote, so it can tolerate intermittent comms.

I've got a researcher that I support who is looking at installing a bunch of computer controlled instruments out in the desert this fall and interfacing with them via a wireless Ethernet system.  We haven't started any field testing yet, but we were looking at a system made by Afar http://www.afar.net/wireless/ethernet-bridge/ that looks pretty good on paper.  Their support engineers have been helpful too.

Thank you for the recommendation!  We'll keep them in mind.

[BobO]

I don't really care if the media is removable.  I just figured that would give the end user a way to install as much as they want for their particular application while saving the manufacturer the cost of building in the memory in every CPU whether it is needed or not.  My real desire is the ability to easily log / write to the storage area and then have it be accessed via USB without special software when I get the chance to connect a laptop to the PLC.  Maybe the file system feature you mentioned will be the ticket.

The issue of file systems, and particularly in relation to removable media, is that you really need an OS to effectively manage them. In an effort to build the fastest PLC at the lowest cost, we chose not to use an OS for the DM1. We definitely have plans for other CPUs in the future, and an OS will likely play a role. You can see where that leads.

I saw that via your start page topics, but if I remember right, it was limited in the types of files that could be downloaded, plus the size limitation.  Is that right?

It's limited to a single file of up to 1MB that can be displayed by your web browser.

[ddubs2248]

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!

[ddubs2248]

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.

[BobO]

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!

The data acquisition part is no problem. I would need a better understanding of how you will be communicating with the server before I would commit to 100hz. I'm certain it is possible, but your comm will dictate whether it is practical.