2

We plan to realize a sensor cable several 1000m long which has ideally every 1-2m a magnetic field sensor on a small 10x30mm platine with microprocessor/FPGA for DSP and I2C on chip communication. Later this will be integrated into an ASIC.

The sensors slaves are thought to do alarm handling/asynchronous messaging to the master/repeater, if a distinct magnetic field value change is too high. Several limitations exist I'm aware of to yield a nearly real-time and cheap and low power consuming cable. It is important that all sensors in the cable check with at least 10Hz the field, the power consumption of the sensors will be in the 50 microA range. All sensors should be powered by the fieldbus cable.

I studied different fieldbus systems

enter image description here

Best for our purpose seem to be CANopen, MODBUS or Profibus (but no sensor voltage supply for this). For a sensor every 1-2 meter with maximum node of 250 we would need every 250-500m a fieldbus repeater (which is not very cheap).

Is there a technical/fieldbus alternative for our purpose if high data rate and is not the most important criterion but keeping the cable cheap?

Would it make sense to create our own fieldbus protocol which maybe can handle 1000 nodes on 1000-2000m without a hardware repeater or even develop a own repeater for our start-up company on our own? We have a engineering team which will do this if it is possible and feasible (price and expense) and funding.

user48953094
  • 149
  • 6
  • I have done some Modbus, and the communications was either serial or Ethernet - neither of which provides power normally. POE could provide power, but the other specs you've mentioned pretty much eliminate Ethernet altogether. I don't know about the other buses, but I think power may be a bigger issue than communications and number of nodes. – manassehkatz-Moving 2 Codidact Dec 11 '17 at 00:42
  • You are better off breaking them down into groups. For example you can have multiple MODBUS "subnets", you either just need a protocol converter (MODBUS TCP to RTU), or multiple serial ports. You would want to do this anyway as a break in the comms line could disable the entire network. Ideally you want to break it down into manageable groups, maybe of 64-128 nodes. Also makes troubleshooting and maintenance a lot easier. – Ron Beyer Dec 11 '17 at 02:39
  • By the way, this would be the same with ControlNET or Ethernet/IP, ProfiNET, ProfiBUS, etc. At some point you need to (and should) subnet. – Ron Beyer Dec 11 '17 at 02:40
  • @manassehkatz I added some comment on specifications. Power is a problem, we have a 4wire cable but probably also a current line cable has to be installed with the cable. Using a field bus and then connecting several slave subnets in Ethernet seems a option to get far beyond 250 nodes as far as I understood some documents and your answer?! – user48953094 Dec 11 '17 at 13:09
  • @RonBeyer Thanks for your interesting comment. So you think with a protocol converter (hardware/software device? didn't find on google, but saw fieldbus X to fieldbus/Ethernet Y converters) we could increase as much the slave number as our necessary data rate would allow it? So basically CANrepeater - 256 nodes with again group/subnets with 10-100 sensors- CANrepeater? – user48953094 Dec 11 '17 at 13:15

1 Answers1

1

Your main problem will be data traffic. If you have 250 nodes that should report in with 10Hz, then that's 2500 messages per second. Your main focus needs to be to keep the data traffic down. Maybe you can create sub-systems, maybe you can send an average at lower frequencies etc.

At a glance, it would seem that CAN is the ideal solution for this. It is rugged, it is real-time, you can get fairly long distances. If including supply, you can do with minimum 4 wires. That is, depending on how much current the nodes draw - sharing supply ground with signal ground is a bit of a dirty solution.

However, since your timing requirements are so high, you'll be looking at the higher baudrates. And you want large distances. Which in turn means that dedicated signal ground and cable shield might be needed. So your specification is contradicting itself: you can't get "fast", "good", and "cheap" at the same time.

In addition, there's not really enough info here to draw any conclusions. I suspect that your specification needs to be revised before you run off to pick a fieldbus.

As for the higher layer fieldbus protocols: unless you need to be compatible with some industry standard computer/PLC, there's no apparent need for CANopen or Profibus etc. These add lots of complexity you can do without, and most are restricted to 127 nodes (for good reasons). If this is a closed system, then a custom CAN protocol might be the ideal solution.

Profibus and MODBUS are also quite old technologies, I wouldn't recommend using them for new design.

Lundin
  • 17,577
  • 1
  • 24
  • 67
  • Thanks for your interesting answer. So a single sensor would measure the field with 10Hz and in case of abnormal field an asynchronous alarm message to the master should be send. These alarms will not happen very often a day. So we rather look towards lots of slaves over miles from my understanding. Your comment on CANopen and "adjusting" this protocol for our purpose is interesting. It also looks to me this is the best protocol to use or to build upon on. But could we still then use then commercial CAN repeaters? Profibus still seems to be widely used protocol, but no power supply. – user48953094 Dec 11 '17 at 13:00
  • We will anyway need a separate current line, as single slave platine with sensor, µC, transceiver consumes around 100µA currently. Our current test cable has 4 wires, 2 for bus, but these small cables will not be able to carry several Amps. Do you think the number of slaves can be increased to much higher number than 250 via subnets/groups (so I have no clue how tricky/possible this is). The system is closed and will be connected to a PC with software for alarm evaluation. Any further hints and I can probably accept the question as it is a bit open (I know) – user48953094 Dec 11 '17 at 13:07
  • It's a bit hard to give you complete info, as we don't know how much evaluation of data of neighboring 4-5 sensors will be necessary to limit failure alarm rate. This is a research project. So we need a adaptable field bus/protocol probably anyway from my current understanding and have to find out how much sensors can be powered/read out in realtime or not and how many slaves/subnets we can put between to repeaters. – user48953094 Dec 11 '17 at 13:21
  • 1
    As 250 kbit/s will not sustain 2500 messages per second: At the [next higher standard bit rate, 500 kbit/s, CAN is limited to 100 meters](https://www.kvaser.com/about-can/the-can-protocol/can-physical-layers/). This could be included in the answer. (I don't know if this would be different with CAN FD or not). – Peter Mortensen Dec 11 '17 at 19:06
  • @PeterMortensen Thanks Peter. This link is interesting. "6 kilometers (20000 ft) at 10 kbit/s" I don't think we would need higher bitrate as we are mainly handling rare alarms. So on this 6km also the number of slaves could be increased by large over 250 with above techniques of subnets/groups? We would need 2 wires for the CANbus and another 2 wires for powering the sensor platines? Currently the platine with sensor, µC, transceiver consumes roughly 10mA. Every 2m a sensor on a 1000m CANbus would mean 5A current, quite much. We have to see how much power a ASIC would save here in the end. – user48953094 Dec 11 '17 at 22:42
  • 1
    @MichaelSchmidt With that high current over 1000m, there won't be much voltage left. You will _definitely_ need a dedicated signal ground separated from supply ground. Perhaps also consider galvanic isolation of the bus. – Lundin Dec 12 '17 at 07:46