Author Topic: CAN bus timing  (Read 3009 times)

0 Members and 1 Guest are viewing this topic.

Online MomchiloTopic starter

  • Regular Contributor
  • *
  • Posts: 122
  • Country: de
CAN bus timing
« on: January 18, 2019, 12:42:16 am »
Hi,
I never used CAN bus before, I probably need it now to solve my problem.
My goal is to measure ~50 different voltages and send ~50 different PWM signals to gate drivers. The used DSC (TI TMS320F28335) is neither able to generate those many PWM signals nor to handle so many analog inputs. A solution could be the CAN bus as seen in the picture.
So every of those 50 cells would get one microcontroller which handles the signals. Maybe you could build something to use only the DSC without the microcontrollers, but the number of cells should be easily scalable without any limitations like not enough pinouts. I would guess a bus is the only solution.
With the CAN bus the microcontrollers can't get the different PWM values simultaneously, respectively the DSC can't output all at once. But the PWM outputs must be timed synchronously to drive the gate drivers for the transistors.
After every microcontroller received the individual value for the duty cycle for the PWM signal, there must be a generated signal by the DSC on the bus, which is addressed to every single microcontroller simultaneously to output the new duty cycle.

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?
The DSC with a 150MHz system clock uses the CAN protocol 2.0B. The reference guide for the CAN module is here: http://www.ti.com/lit/ug/sprueu1/sprueu1.pdf
I appreciate every more or less helpful answer, thanks in advance :)

Best regards
Momchilo
« Last Edit: January 18, 2019, 12:47:40 am by Momchilo »
 

Online langwadt

  • Super Contributor
  • ***
  • Posts: 4857
  • Country: dk
Re: CAN bus timing
« Reply #1 on: January 18, 2019, 01:04:33 am »
CAN bus is only  500kbit, you can go faster but not much
 
The following users thanked this post: Momchilo

Online MomchiloTopic starter

  • Regular Contributor
  • *
  • Posts: 122
  • Country: de
Re: CAN bus timing
« Reply #2 on: January 18, 2019, 02:24:19 am »
CAN bus is only  500kbit, you can go faster but not much
So I have 50*16Bit+50*12Bit=1.4kbit data to transfer.
With 500kbit/s, the 1.4kbit would need 2.8ms. That would take way too long. The PWM frequency will be 12kHz. That means there are 83µs time to do everything. The calculations need the most time for the control. Hence, the data transfer must be done in like 5µs. To achieve this, the transfer rate must be at least 280Mbit/s. I think this is impossible between a microcontroller and the DSC. This thread is unnecessary, sorry about this. I knew the rate, but didn't do the simple math.
I have to research for alternatives. Maybe just one big FPGA instead of the microcontrollers. In this way every time cells are added, the program on the FPGA must be updated |O
 

Online Niklas

  • Frequent Contributor
  • **
  • Posts: 404
  • Country: se
Re: CAN bus timing
« Reply #3 on: January 18, 2019, 08:42:00 am »
The CAN bus frame contains quite a lot of overhead bits for the identifier, checksum etc. Even with standard identifiers and just 16 bits of data you will end up with approx 60 bits on the bus. You can save some time by putting 4x16 bits in each CAN frame, do HW filter on identifier and the select the appropriate data bytes. With 8 bytes of data, standard identifier and 1 Mbit/s it will take 100 us/frame.
It is also possible to send the PWM data frames with different identifiers and then use another identifier as a global update.
 
The following users thanked this post: Momchilo

Online fchk

  • Frequent Contributor
  • **
  • Posts: 279
  • Country: de
Re: CAN bus timing
« Reply #4 on: January 18, 2019, 09:33:59 am »
Hi,
I never used CAN bus before, I probably need it now to solve my problem.
My goal is to measure ~50 different voltages and send ~50 different PWM signals to gate drivers. The used DSC (TI TMS320F28335) is neither able to generate those many PWM signals nor to handle so many analog inputs. A solution could be the CAN bus as seen in the picture.

I think CAN is the wrong answer.

I'd use an FPGA for this. FPGAs are able to generate 100s of PWMs, and if you worry about scaling - there are FPGAs with over 1000 pins and millions of logic blocks. Everything would be fed from a single clock and be synchronous on the spot.

The FPGA would also control all the ADCs, which is also no problem at all.

Since the FPGA is programmable hardware everything automatically runs in parallel, and the timing is always fixed.
 
The following users thanked this post: Momchilo

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4705
  • Country: au
  • Question Everything... Except This Statement
Re: CAN bus timing
« Reply #5 on: January 18, 2019, 10:23:42 am »
Lets say we strip it all the way back to basics, the slowest part of this link is the communication, so lets keep him as small as possible with the cost of a small amount of shifting to get out the data you want.

You have 50 ADC modules, so a 7 bit identifier will cover all of them, + 12 bits of ADC value. ok, so 19 bits,
Now you want to send that in under 1uS, It would require at minimum a 18.2 Mbps data rate. (2.3MBps), This is about 5 times higher than what even the newer CANFD spec can accomplish,

So with normal CANbus, which should be 1Mb max, but if another poster thinks 500K, then 500K it is. to start no overhead, low level only. it would take 38uS to read 1 ADC value + Identifier, If you where very cluey, you could have every ADC board scrape the identifier and just fire off there value in turn, with the first ADC acting as the sync. costing only 24uS for each extra value. adding up to a grand total of 1.238 milliseconds for all 50 readings,

So now for alternatives if you really need it to be much faster, You have 3 UARTs, and an SPI that look like they can pull off cpu/2 and cpu/4, The SPI with a shift register for the chip select would be nice and fast. if cpu/2 works, you could read off all your boards in as little as 8uS + copying to RAM, or the more reasonable cpu/4 in 16uS, you set the SPI to read a 12 bit value, (its settable length), the shift register is used to load the first chip select, your ADC board is using the SPI register as a FIFO, so its ready to go, at max clock speed, 12 bits are pulled through, stored somewhere and the chip select shift register is clocked 1 pulse to select the second ADC and so on.
 
The following users thanked this post: Momchilo

Offline max_torque

  • Super Contributor
  • ***
  • Posts: 1327
  • Country: gb
    • bitdynamics
Re: CAN bus timing
« Reply #6 on: January 18, 2019, 02:49:34 pm »
Are you saying you need to syncronise all your PWM outputs? ie the rising edges at the start of each cycle must align?  That requires all the pwm clocks to be aligned themselves and not just the moment at which the PWM duty cycle is actually updated!  You'll need some sort of parallel "clock" line to do that.  (ie to distribute a reference timing pulse all the slaves can synchronise too) remeber that the clocks on all the slaves will be at slightly different frequencies and drift with any variations in temperature etc!

Can you explain what you are actually trying to achieve?  50 ADCs and 50 PWMs sounds like a nightmare to me!
 
The following users thanked this post: Momchilo

Offline max_torque

  • Super Contributor
  • ***
  • Posts: 1327
  • Country: gb
    • bitdynamics
Re: CAN bus timing
« Reply #7 on: January 18, 2019, 02:52:59 pm »
BTW, this looks like some form of BMS?   Are your ground potentials all the same or do you need galvanic isolation as well?


Is there no way each node can work out the necessary pwm to output based on the voltage it measures?

CAN can run at up to 10Mbaud (with CAN FD hardware) over short distances
 
The following users thanked this post: Momchilo

Online MomchiloTopic starter

  • Regular Contributor
  • *
  • Posts: 122
  • Country: de
Re: CAN bus timing
« Reply #8 on: January 18, 2019, 04:16:00 pm »
Can you explain what you are actually trying to achieve?  50 ADCs and 50 PWMs sounds like a nightmare to me!
BTW, this looks like some form of BMS? Are your ground potentials all the same or do you need galvanic isolation as well?
This is part of a three phase multi-level converter. For every additional level you need an additional dc link voltage (caps) as seen in the attached picture. In this example it's one high side of one half bridge of a 6-Level-Converter. The corresponding low side is missing for the half bridge in the picture and this is needed for every phase. That means 30 voltages and 30 transistor pairs. But the converter should be easily scalable with additional levels, therefore the number 50. Then 8 levels (6*7) would be possible. This way you could easily build converters for different dc voltages with the same clean sinusoidal waves but higher voltages.
Same project, other problem: https://www.eevblog.com/forum/projects/measuring-small-differential-voltages-with-high-common-voltage/

Is there no way each node can work out the necessary pwm to output based on the voltage it measures?
This isn't possible. Because you need the three phase shifted sinusoidal outputs. The control is quiet complex and all the pwm outputs are depending on all the dc link voltages, phase currents, frequency and so on.

CAN can run at up to 10Mbaud (with CAN FD hardware) over short distances
Unfortunately the DSC doesn't have CAN FD hardware.

Thanks to you all, you helped a lot so far. At the moment I think the best solution would be one FPGA, connect via XINTF with the DSC. The FPGA will output all PWM signals and get all the inputs of the ADCs. If I implement it this way, the disadvantage would be the much more complicated scalability.
« Last Edit: January 18, 2019, 04:40:11 pm by Momchilo »
 

Offline max_torque

  • Super Contributor
  • ***
  • Posts: 1327
  • Country: gb
    • bitdynamics
Re: CAN bus timing
« Reply #9 on: January 18, 2019, 07:21:06 pm »

This is part of a three phase multi-level converter. For every additional level you need an additional dc link voltage (caps) as seen in the attached picture. In this example it's one high side of one half bridge of a 6-Level-Converter. The corresponding low side is missing for the half bridge in the picture and this is needed for every phase. That means 30 voltages and 30 transistor pairs. But the converter should be easily scalable with additional levels, therefore the number 50. Then 8 levels (6*7) would be possible. This way you could easily build converters for different dc voltages with the same clean sinusoidal waves but higher voltages.

It looks like a catastrophically complicated way of achieving, well, i'm not sure what really   :-DD  Why not just have a variable level DC link?

What does this converter drive?
 

Offline jbb

  • Super Contributor
  • ***
  • Posts: 1265
  • Country: nz
Re: CAN bus timing
« Reply #10 on: January 19, 2019, 07:57:01 pm »
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.
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4209
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: CAN bus timing
« Reply #11 on: January 19, 2019, 09:06:32 pm »
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?
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.
 

Offline IDEngineer

  • Super Contributor
  • ***
  • Posts: 1950
  • Country: us
Re: CAN bus timing
« Reply #12 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.
 

Online langwadt

  • Super Contributor
  • ***
  • Posts: 4857
  • Country: dk
Re: CAN bus timing
« Reply #13 on: January 20, 2019, 01:24:18 am »
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.

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 


 

Offline Doctorandus_P

  • Super Contributor
  • ***
  • Posts: 4004
  • Country: nl
Re: CAN bus timing
« Reply #14 on: January 20, 2019, 02:45:10 am »
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.
« Last Edit: January 20, 2019, 02:54:16 am by Doctorandus_P »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf