Skip to content
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

Open
jwcrawley opened this issue Oct 2, 2017 · 13 comments
Open

[FR] Communication protocol for Microprocessor bus #7823

jwcrawley opened this issue Oct 2, 2017 · 13 comments
Labels
T: Feature Request Features requested by users.

Comments

@jwcrawley
Copy link


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:

  1. I hook up my closed loop board.
  2. I tell the closed loop board to calculate esteps for axis. It injects the appropriate steps to calculate accurate esteps. It also does the same for velocity, accel, and jerk.
  3. Closed loop board then uses PJON to tell Marlin that "X Axis esteps are 12345", "X axis velocity, accel, jerk = 50mm/s, 5mm/s^2 , 2mm/s^3"

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.

@jwcrawley
Copy link
Author

jwcrawley commented Oct 2, 2017

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.

@Grogyan
Copy link
Contributor

Grogyan commented Oct 2, 2017

From my own investigations over the past few weeks, primarily on the communication bus/protocol, to allow for extend ability.
My personal preferred, which is widely used in automation and automotive industries is CAN.
Like you mentioned, in some cases a transceiver, or small micro needs to be used as an interface. Looking at cost vs optimally working, CAN is the best option IMO.
From a cost perspective, a $400 machine, with a $3 additional part is very insignificant, but reliability is very high.

Just my 2C
Also i've already raised #7735 in relation to this

@jwcrawley
Copy link
Author

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.

@Grogyan
Copy link
Contributor

Grogyan commented Oct 2, 2017

BUS Comparisons
I used this, and on page 8, is a table comparing various busses.

Case for CAN in automotive and auomation
Is a good specification guide to CAN.

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.

@jwcrawley
Copy link
Author

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.

@Grogyan
Copy link
Contributor

Grogyan commented Oct 3, 2017

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.
Looking at the datasheet for the STM32F103, it has CAN baked onto the silicon, and as such a micro would be ideal for a simple Remote Display, operating over CAN with no additional transceiver required.

@bobc
Copy link

bobc commented Oct 3, 2017

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.

@Grogyan
Copy link
Contributor

Grogyan commented Oct 3, 2017

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.
CAN is relatively slow, at about 1Mbit/s, however this is plenty fast enough for where it is used.

@bobc
Copy link

bobc commented Oct 3, 2017 via email

@Grogyan
Copy link
Contributor

Grogyan commented Oct 3, 2017

I stand corrected

@Grogyan
Copy link
Contributor

Grogyan commented Oct 3, 2017

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.
There are others here that are more knowledgeable about protocols.
We have I2C already inplemented
CAN already widely used in industrial automation (including 3D printing) and automotive systems, but not yet a thing in Open Source 3D printers, this may have been due to cost.

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.

@thinkyhead thinkyhead added T: Feature Request Features requested by users. C: Hosts & Protocols labels Feb 9, 2018
@thinkyhead
Copy link
Member

thinkyhead commented Feb 9, 2018

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.

@alexxy
Copy link
Contributor

alexxy commented Nov 6, 2018

Another possibility is to use something like NT bus. This concept is used by STorM32

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T: Feature Request Features requested by users.
Projects
None yet
Development

No branches or pull requests

6 participants