-
-
Notifications
You must be signed in to change notification settings - Fork 19.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FR] Communication protocol for Microprocessor bus #7823
Comments
Since this is a pretty high-level concept Feature Request, ill provide another good example. Problem: I want to have a zoned heating system, in which I'll have a lot of heaters and thermistors. Without microprocessor comm bus: Right now, to do this would require watching the Mosfet and generating an appropriate thermistor value to represent the sensor fusion of, say, 10 thermistors and 10 wirewound resistors. My microprocessor would handle the actual data and toggle zones on and off as needed. The problem is I don't know what the set point is. All I know is that the mosfet for the bed is on, and I set a temp to go to Marlin. And when my therm temp goes too high, Marlin then shuts off the mosfet. At best, I have to derive the real set-point from instantaneous pulses - and that's ugly. With the proposed FR: Marlin would generate a message over PJON: "Bed heater controller, please set target temp to 110C. Alert when finished." And the bed controller would handle the logic of sensor fusion and zone controls to handle the bed heating request. |
From my own investigations over the past few weeks, primarily on the communication bus/protocol, to allow for extend ability. Just my 2C |
Oh you have my support on any protocol that can enable having multiple micros talking to each other over a bus! My only concern with CAN, was of the old engineering saw: "Fast, Good, Cheap" pick 2. Well.. I chose Good and cheap. Except, I then traded cheap for free, by suggesting using PJON. It's compatible with: Atmel, ARM, RasPi, ESP12/32 and plenty other micros without extra hardware. It's slow, around 2-3KB/s. It would only require a code-change to implement on any platform. The idea was similar to that of desktops - there doesn't have to be just 1 bus. There can be a slow bus like SMBus or PMBus, along with high speed interconnects like CAN or Ethernet. Pretty much, we can have PJON right now on existing hardware, but CAN would require hardware upgrades. |
BUS Comparisons Case for CAN in automotive and auomation I can't remember where I found a table that went over a lot of various busses, pros and cons of each. Most were short range, ideal for inter communication on the same board. |
I looked over CAN spec and available parts, and I couldn't find a CAN transceiver for less than $3. Given that an Arduino Nano is $2, and a Maple Mini (STM32F103) is $4, that's a significant addition to a cheap microprocessor for semblance of networking. |
Digikey search found a lot of transceivers under $3. Given the underwhelming spec of the Arduino Nano and STM32F103. having CAN on the main processor would require a beefier micro, even the LPC1768 used on the Re-Arm has CAN on the silicon, plus it is a pretty beefy micro. |
There's some confusion here between CAN controllers and transceivers. The CAN controller handles the framing and protocol, and is either in the MCU or an external chip like MCP2515. The CAN transceiver is a separate function and does the low-level driving of the differential CAN bus. Whether the CAN controller is external or external, you still need the external transceiver. The transceiver is pretty cheap, around $1. I think CAN makes sense if you have a CAN controller on the chip, like many low end Cortex M3 MCUs do. STM32F103 is a capable chip, and cheap, seems ideal for remote devices. The Due also has a CAN peripheral. I'd like to have a play around with CAN, but I have to move house first... On the subject of PJON, what physical layer is proposed? I would really avoid any bit-banging, it really chews up cycles. We've got about 3 FRs asking for new protocols, #7742 is intending to use I2C. It seems like it would be good to have a single solution for talking to remote devices, instead of 3 different protocols. |
Yes each CAN Node, including the controller, requires a transceiver, unless already like @bobc mentioned, the transceiver is baked onto the same silicon. Essentially, these cheap transceivers just helps make the system idiot proof. I2C as suggested in #7742 is a poor choice, as the bus is not designed for long distances, and has low EMI Immunity. It is fast. |
No, each CAN node requires a _controller_ and a _transceiver_. The
controller may be in the MCU, an external transceiver is still required.
The transceiver is required to drive the CAN bus, it's not optional.
CAN is certainly better than I2C for noise immunity, I think I2C will
perform poorly if it is next to switching loads such as heaters, fans and
motors. I2C at "standard" rate is 400kHz, somewhat slower than CAN. The
main advantage of I2C is that it is very simple and already in AVR MCUs and
many ICs.
The funny thing is that RepRap printers used to have RS485 to connect
boards within the printer, but they abandoned that idea. Running a robust
comms network is not as simple as most people think.
…On 3 October 2017 at 21:17, Grogyan ***@***.***> wrote:
Yes each CAN Node, including the controller, requires a transceiver,
unless already like @bobc <https://github.com/bobc> mentioned, the
transceiver is baked onto the same silicon.
Essentially, these cheap transceivers just helps make the system idiot
proof.
I2C as suggested in #7742
<#7742> is a poor choice,
as the bus is not designed for long distances, and has low EMI Immunity. It
is fast.
CAN is relatively slow, at about 1Mbit/s, however this is plenty fast
enough for where it is used.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#7823 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA7VRzgNfs5xVV_-WQTOwiYN99PG8q2Nks5sopZfgaJpZM4Pq3IM>
.
|
I stand corrected |
From what I remember of the reasoning behind the use of RS485 in the day of Makerbot Cupcake, was to keep all extruding stuff on a separate board, due to limitations of available silicon supported by Arduino. With regard to PJON, I don't know if this a single master-slave, a master-multi slave standard. All I know is that commercial 3D printers that blatantly rip off the RepRap project and Marlin Firmware, will likely follow suit when the feature is there. |
The demand for this kind of feature is extremely low and devs have a lot on their plates dealing with bugs and 32-bit migration, so it's unlikely this will be implemented anytime soon. But, you may be able to hire a developer for $$$ if you need this feature very much. |
Feature Request
Greetings. I'm developing hardware to accompany Marlin and other printer controllers. The way I'm doing this, is by using separate microcontrollers and doing the work there, and handling the logic and code away from Marlin. The idea is that I can build a clean interface that works with Marlin, Duet/RRF, Smoothie and future releases.
As an example, I am currently working on a closed-loop controller that is plug-and-play with existing hardware. https://gitlab.com/crankylinuxuser/closed_loop_system
With this design, I'm shimming STEP/DIR/EN through my ARM board, providing closed loop with sensors, and then outputting the modified STEP/DIR/EN to the stepper socket. This works as a drop-in for pretty much any board that provides the standard stepper interface. Note that the data only flows from the Marlin controller TO the aux board.
What I am proposing is a low bandwidth protocol, like https://github.com/gioblu/PJON , that would allow me and others to talk to a shared bus to share feedback data. As an example what this would enable, is the following:
Ideally, if/once this feature is added, we can also request RRF and Smoothie to incorporate this. It would open up a new avenue of sub-microprocessors being able to offload Marlin functions. Ideally, I am proposing a clean interface in which to do this.
Ive also looked at other protocols. Here are my notes/comments about them.
PJON - compatibility over nearly every type of microprocessor and SBC. Slow. Published standard and Arduino reference code.
CAN - STM32 native support, but requires transceivers for Atmels and RasPis
I2C - Reports from Smoothie it is very dirty bus.
SPI - chip manufacturers Dont have good compatibility
RS232 - Baudrate hell, timing requirements, and 1:1 comm.
The text was updated successfully, but these errors were encountered: