Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: timk5000 on March 15, 2018, 04:38:25 PM
-
I am looking for some suggestions on which equipment that will work best for a project.
I have tried to attach a image to help describe the layout. What I would like to do is put remote IO at each material supply box. Run wire from each sensor along the supply tubes to the IO. and connect the air valves to the IO. Connect the each remote IO module to the PLC with ethernet cable.
My question, Is this the proper way to do this and what equipment would be best. I prefer to use the DO More for the PLC,
Any suggestions would be very helpful
-
I have done similar for the plants I build. I think a BRX used as the remote IO to sense the inputs and operate the valves would make sense. The master PLC wouldn’t actually need much if any IO.
-
The online manual for the BRX has a section for Remote IO but all it says is for future release.
https://cdn.automationdirect.com/static/manuals/brxuserm/brxuserm.html Chapter 14
Haven't really found any examples or instruction on how this would work. Can I just connect three BRX with Ethernet using a hub and CAT5 or do I need something else.
Or use a Do-More with ethernet and a hub connected to 2 BRX with the IO for the sensors and valves.
Thanks
-
There isn't any native BRX remote I/O yet, but they're still Do-Mores, so you can use H2 or Terminator remote racks, or even generic Modbus RTU or TCP or Ethernet IP remote IO. I think BRX remote I/O adapters are supposed to be out this year.
-
Does the Ethernet Do-more work as the host controller for the Protos I/O series?
-
Does the Ethernet Do-more work as the host controller for the Protos I/O series?
I assume the Protos has a Modbus/TCP head, so we could talk to that.
I don't have a formal launch date yet, but the BRX based remote I/O heads (BX-DMIO, BX-EBC100, BX-MBIO) *should* ship in late Q2. The holdup was UL, but we finally got approval. Now it's just getting into the launch queue at ADC. The product management team at ADC is working hard, but launch resources are finite.
-
Thanks guys
-
I assume the Protos has a Modbus/TCP head, so we could talk to that.
They do, and I think they do EIP as well. Not sure if they can handle explicit messaging from a DM, or if it's implicit I/O only.
-
...or if it's implicit I/O only.
And that has become a higher priority to us. It's way too early to make promises, but I'd love to see support by DmD 2.4 or so.
And BTW, barring something ugly, DmD 2.2 will go live Monday.
Key features:
1. Support for GS4
2. DNS support in EMAIL
3. TLS support in EMAIL (BRX only)
4. INI (Immediate Input) instruction (BRX only)
5. Installing in "Program Files (x86)"
DmD 2.3 will come fairly soon afterward and will coincide with the next phase hardware release.
-
Thanks for the DMD 2.2 preview - cool stuff!
-
1. Support for GS4
Wow, I am getting ready to start programing a BRX with 3 GS4 drives. How easy is it going to make my life?
-
Wow, I am getting ready to start programing a BRX with 3 GS4 drives. How easy is it going to make my life?
It's support for the EDRV100 with GS4 drives. If you use it, real easy, but some are unwilling to spring for the EDRV100.
-
I bought the Modbus ethernet cards for each of the drives. GS4-CM-MODTCP
-
Cheaper, but basically no benefit other than performance. You'll be using MRX/MWX just like you would through the 485 port. With the EDRV100, it's supported through the Ethernet I/O master. All of the relevant make-it-go registers are mapped to a structure, and the GSREGRD/WR instructions make register access painless.
-
I guess it would be more cost effective to to use the GS-EDRV100 over multi-drop 485 if you had 4 or more drives
-
No. EDRV100 only talks to a single drive.
-
Why arn't the multi-drop communications implemented? Seems like a natural configuration.
-
As a simple Modbus device, sure, and the gateway does exactly that. As the drive adapter, it reports as an EBC, and although it could support multiple devices, it isn't nearly as easy to implement, and 485 network congestion becomes a real problem at the slow baud rates used.
But compared to the price of the motor and drive, is it really that big a deal?
-
Depends on the application, it could be. The GS4 drives have the Modbus $80 option card. Compared to the GS-EDRV100 $200 solution. Most of the machines of any size that I have worked on in the last 10 years have all been some form of Ethernet I/O, If I had a slew of motor drives scattered all over a warehouse or assembly line, more than likely there is going to be Ethernet all over the place. That's why I chose the GS4 drives, because it had that option. If I was trying to reduce cost (like most OEM's) and save the $80 and more if I went to a less capable drive, especially on large installations, I would use the 485 multi-drop if I was only changing speeds occasionally, simple start stops and monitoring.
s
-
We've talked about both multi-drop and/or cost reducing, it just hasn't been a super high priority. Significantly simpler programming with the EDRV100, but it isn't difficult with Modbus.
-
In our industry spares have to be factored into the cost analysis. So that is why I try to stay with a single architecture so that spare parts are common everywhere. Even did this with AB. PLC with no I/O and Point Block I/O both local and remote.
With our product we probably won't go to actual remote I/O because we are trying to keep our master code base completely common to all projects. So anything custom to a particular job that must be added goes in its own PLC. We use the same PLC for that even if it costs more, because we get to reduce our spare budget.
-
Why arn't the multi-drop communications implemented? Seems like a natural configuration.
The MB-GATEWAY does exactly that. However, it's just Modbus/TCP, NOT Do-more's native "Ethernet I/O". You have to do all the polling via your own MRX/MWX of the relevant drive parameters, along with handling of drives going "offline".
GSEDRV100 takes care of all of that (but only one per drive). That is the trade-off.
-
Cheaper, but basically no benefit other than performance. You'll be using MRX/MWX just like you would through the 485 port. With the EDRV100, it's supported through the Ethernet I/O master. All of the relevant make-it-go registers are mapped to a structure, and the GSREGRD/WR instructions make register access painless.
And now that we've got UDT's (user types, not date/time), you should be able to create one for the drive data map and overlay it over the Modbus registers, so it's just about as cool as using the EDRV.
-
And now that we've got UDT's (user types, not date/time), you should be able to create one for the drive data map and overlay it over the Modbus registers, so it's just about as cool as using the EDRV.
Great Idea!