Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: brucek on August 21, 2020, 09:02:11 AM
-
Just wondering if there are any plans to add to the 16 remote rack limit in Domore? If you start adding drives to the list 12 drives (using the edrv100) and 4 remote I/O racks don't really seem like much. This is probably a whole redesign thing but 16 seems a bit low. I am using the modbus TCP for drives just so i don't get to far into the 16 limit. We have (with drives at plants) 5 cold feed bins 1 rap, 1 Asphalt pump, 1 Exhaust fan, 1 Burner Blower, and now the company wants to put at least 3 other components on drives at every plant. This would be 12 Drives that if we used EDRV100's we wouldn't have much room for remote racks.
Also if you use the terminator you can make the remote rack as big as you want with just adding power supplies but the BRX and H2 versions are limited to the 8 Card or Rack size limits. I have had issues with losing inputs on the terminator series 120v inputs so I'm buying just the BRX series for remote racks now which puts my remotes to 8 cards.
I'm sure there are reasons for the 16 limit but it just seems small to me if you were to use DoMore in a big project. Or you just have to use modbus but it is awful nice to have the drive stuff in the project.
-
Its kind of funny isn't it? The BRX is considered a MICRO Brick PLC and everyone wants it to DoMore!
-
Funny, I was thinking the same thing.
-
The major consideration was simply wanting the comms to remain perfectly stable. I/O scans are semi-synchronous, which can result in lots of packets arriving at the same time. While that isn't necessarily bad, it does increase the chance of packets getting dropped, which would force retries on I/O. This isn't the first time we've gotten the request though. I'll look at what it would take to increase it if possible. How many is enough?
-
There was also some concern of the memory burden. Doesn't seem like a big deal until need 10s of things. Might be a way to optimize that though. I/O scans don't move a lot of data, but we plan for worst case packets. Could probably come up with a smarter buffer allocation that would greatly reduce memory usage.
-
I don't know whats involved with the comms but 16 remote isn't bad if there was a way to separate the drives as a new system. 16 remote racks and 16 drives, but I'm sure more is better on the drives end since a lot of things are going drives that didn't have to before ( at least for us). Pretty sure its to late to make drives different then remote or a drv100 gateway that could have so many drives per gateway that would count as 1 remote. That is probably a different company then you guys though.
I never thought of the BRX as micro because of what it could do but that is probably because i just think of DoMore not the package its in.
The modbus works its just a bit more cumbersome then the edrv100's.
-
Pretty soon they're going to have implicit Ethernet/IP and you can put all the drives on there.
Come to think of it, are you going to make E/IP EBCs? Good for AB retrofits and might be an option for Do-More as well.
-
Of course I don't know your processes, but sometimes it simplifies the controls to break things up into multiple PLC's. Then use PEERLINK , Modbus or Packet coms to coordinate between systems or Master/Slave arrangement. This can allow for flexibility for adding or removing parts of the system and future growth.
-
Good point. If they're really separate processes I'd rather have each on its own controller for robustness anyway. That way each process is a little insulated from unrelated stuff going egg-shaped.
-
Some may see it as overkill, but the highest cost of most any system is software development. The BRX is so affordable that you can justify have multiple CPU's in a system. It can break up the complexity to make individual processes easier to develop. Like CG said modifying or even troubleshooting one part won't screw up something else. The reliability of Ethernet communications and the tools available for passing data between PLC's make it very doable.
-
Yeah, plus I was thinking of reliability in service. If one PLC breaks and takes down its process, I'd rather that "process" not be the entire plant, assuming the process definition would allow the pieces to continue to run in that scenario. Find the single points of failure and get rid of as many of them as you can.
-
When i say plant its an asphalt plant not a building plant with 1 plc running the whole building. Typically its < 500 I/O With some analog and now I'm starting to put counter cards in for the Tachometers. Seems to do better with reducing noise going thru Ethernet then the cheap shielded cable we have. That does require more PLC's because i can't have more then 8 HSIO cards in a rack of brx. I just set up a portable plant this year and turns out we aren't using it this year so i have to wait and see how the HSIO cards do. I went from 1 PLC to 3 on this plant with more coming if the HSIO works so i can put them at the other end of the plant to capture more Tach's. It worked on the bench so I'm pretty sure it is going to work but hasn't proved itself in practice yet. Another plus is it cuts down on the number of wires to hook up when the plant moves.
Like i said the drv100 just makes it easier then modbus but modbus isn't that bad so i can live with it, just thought I'd ask.