Electronics > Projects, Designs, and Technical Stuff
CAN bus timing
jbb:
Ah, the Modular Multilevel Converter (MMC, MLC, M2LC). It’s quite common to deploy a controller (typically an FPGA) per cell.
In terms of practical deployment (ie winning a design space), there are some things to be aware of:
- for DC voltages under ~ 2kV, a classic Neutral Point Clamped converter will be hard to beat. ABB offers a 5 level (per phase) Active NPC that is weird but effective.
- for applications around and over ~ 2kV, isolating control signals is difficult and tends to rely on plastic optical fibre. Therefore the number of comms signals should be limited to tx and rx only
- typical loads (eg power distribution, motors etc ) tend to be rated in fixed voltage classes and scale their power by changing the current rating. This sadly means that the fine voltage scaling of the MMC doesn’t work out too well.
Jeroen3:
--- Quote from: Momchilo on January 18, 2019, 12:42:16 am ---Every PWM value is 16Bit and the voltage measurements are at least 12Bit values. So no large amounts of data, but many. The DSC is chosen, but for the microcontroller everything would be possible.
I don't expect a complete calculation or something similar, but hints where to start would be really nice or ballpark numbers. Is it more like 1ms for the complete data transfers or is it possible in 1µs? Like how long does it take to receive 16Bit and then send 16Bit to a microcontroller? Is it possible to talk to every microcontroller at the same time via CAN bus?
--- End quote ---
People often misunderstand this about CAN bus. Once more then: CAN bus is a broadcast system. All nodes receive all data and acknowledge receiving it.
The node can then choose whether the message with ID x is relevant or not. The ID of a CAN frame describes the contents of the message. The contents of the message should always be the same variable. Most of the tooling available expects this!
Yes, you could use the ID for addressing, but it is not how it was designed. Common layers above CAN bus often apply a system like this, where a part of the ID field is taken out for node addressing. Without compromising the message priorities. Such as J1939.
However, if you're going for a custom system and you have high demands, you could also use the ID field as part of your data. Possibly lowering the byte count in the frame.
You only need 6 bits to "address" the 50 modules. Thus technically you could fit this in a 2.0B frame with one data byte. Or three 2.0A data bytes.
CAN bus cannot work for clock synchronization. If you want a bus system for that, I suggest you find a protocol that you can be put into manchester coding for clock recovery.
IDEngineer:
Maybe I missed it in my scanning of this thread, but: Must your update rate be literally every PWM cycle? Or can we, ahem, address the problem a different way? Such as use a freerunning PWM block (at whatever frequency you wish) and just update it at a different, lower frequency?
If the latter, you probably "CAN" do this. The PWM channels can be simple freerunning hardware whose period is set by a CAN write.
I once did a stepper motor drive system like this, years ago, for a industrial class laser printer. Even got a patent on it (long since expired). Instead of having the MCU directly drive the phases, I set up a simple hardware block driven by a clock controlled by a hardware writable latch. Dropped the overhead to nearly nothing, yet retained total control over what the motor was doing. Hardware cost was almost nothing but it allowed the use of a far less expensive MCU than what the original architecture had budgeted.
Note that such a system would also be easy to sync across any number of channels, if that happens to be a requirement as asked by other respondents.
langwadt:
--- Quote from: IDEngineer on January 19, 2019, 10:52:46 pm ---Maybe I missed it in my scanning of this thread, but: Must your update rate be literally every PWM cycle? Or can we, ahem, address the problem a different way? Such as use a freerunning PWM block (at whatever frequency you wish) and just update it at a different, lower frequency?
If the latter, you probably "CAN" do this. The PWM channels can be simple freerunning hardware whose period is set by a CAN write.
I once did a stepper motor drive system like this, years ago, for a industrial class laser printer. Even got a patent on it (long since expired). Instead of having the MCU directly drive the phases, I set up a simple hardware block driven by a clock controlled by a hardware writable latch. Dropped the overhead to nearly nothing, yet retained total control over what the motor was doing. Hardware cost was almost nothing but it allowed the use of a far less expensive MCU than what the original architecture had budgeted.
Note that such a system would also be easy to sync across any number of channels, if that happens to be a requirement as asked by other respondents.
--- End quote ---
that's is basically how many CNC controllers work, ever millisecond or so the controller ask the servos/stepgenerators
what their positions are and tell them what speed to move at
Doctorandus_P:
CAN bus can go upto 10Mbit/s over short distances, just like RS485, but maximum bitrate diminishes with cable length and the quality of your cable and termination resistors.
CAN frames do have quite some overhead, and I don't know if that is acceptable for you.
You can significantly speed things up if you use a custom protocol.
For example, you can define a single master, which sends a magic ping packet, which gets receivedby all nodes at a regular interval, and each node responds with a 2 byte packet with measurement data after a fixed delay. Those nodes could even sniff each other's data and count bytes, and inject their own so you have an almost continuous datastream. This is doable, but requires carefull programming.
The master would also be able to address each node individually, for example for fine tuning sensitivity parameters or adjusting the delay or other house keeping tasks.
The "ping" which triggers the information cascade would then be some special packet with "magic content" to distinguish it from normal communication.
10Mbit/s is still relatively easy and cheap to do. If that is not fast enough it gets progressively more expensive.
If you need galvanic isolation of the nodes, the ISO1050 is a remarkably cheap CAN transceiver from Ali / Ebay / China / Etc.
Probably hard to beat from other sources. But Beware, I haven't checked its maximum baudrate.
Something else to be aware of:
Normal RS485 (and I think also CAN) is limited to 32 nodes. But there are RS485 drivers which are only 1/2 or 1/4 load to the cable, so you can put 64 or 128 nodes on a single daisy chained cable.
A very brief comparison between RS485 and CAN:
On the signal level both busses are half duplex and use differential signalling. RS485 pulls one wire high and the other low for a "zero" and vice versa for a logical "one" on the bus.
CAN uses an "active" state where the voltages on the wires are pulled apart, and a "passive" or "recessive" state where the voltages on the wires are pulled together by the termination resistors on the wires.
For RS485 that's about it. How bits are defined is not in the RS485 standard, but left up to the user, and it is very common to connect RS485 transceivers to the Uart of a micro controller.
CAN drivers can be used similarly to RS485 drivers, but if you use microcontrollers with a built in CAN peripheral, then CAN has extra defined layers and all kind of pre defined signals and packets. These are defined to make it possible to make vendor independant peripherals, which makes it possible that you can buy a cheap CAN sniffer from Ebay / Ali / whatever that sniffs all kind of interesting things from the also standarised CAN connector somewhere hidden under the dashboard of your car.
The "active" and "passive" (recessive) state of CAN (compared to RS485) makes it possible to give priorities to packets and do active collision avoidance without damaging packets, but if you want to make use of that you really need uC's with a CAN hardware peripheral.
Probably a good start reading for more details on Wikipedia.
Navigation
[0] Message Index
[*] Previous page
Go to full version