Cannot Find a way to contact, author

[bondus]

Cannot Find a way to contact, author

[bondus]

You found a way. It's improved now

[SteveJWallace]

Hey, I was trying to reach out to you. I'm currently building a Jubilee toolchanger and implementing it using 2. SKR Pro 1.1 boards and klipper. Most Jubilee printers currently are built with duet2/3 and tool boards. A future project was to build a tool board but someone pointed me in your direction.

…

On Wed, Jun 24, 2020, 5:45 PM bondus ***@***.***> wrote: You found a way. It's improved now — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHE2SJYTPHLGEYEQ6ZNZ6DRYJXY7ANCNFSM4ODQ7YLQ> .

[bondus]

Klipper screamed to get a board like this, the design of klipper makes it very easy. A multi head printer needs a product like this.
I'm stuck in a horrible world of SMT assembly and manufacture at the moment. With some luck there will be some working boards for sale at the end of the summer.

[SteveJWallace]

If you want any testers etc, I'm quite technical. I'm not a professional EE by any means but have worked in embedded systems as a software developer and electronics hobbyist. My only issue with klipper is that it's uses a serial protocol that isn't really best served over Can.

…

On Wed, Jun 24, 2020, 8:26 PM bondus ***@***.***> wrote: Klipper screamed to get a board like this, the design of klipper makes it very easy. A multi head printer needs a product like this. I'm stuck in a horrible world of SMT assembly and manufacture at the moment. With some luck there will be some working boards for sale at the end of the summer. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHE2SKIDNRNBUOZLDNTYN3RYKKUTANCNFSM4ODQ7YLQ> .

[bondus]

Where are all the EEs when you need them? Hidden in some corporate basement!
The current CAN implementation tunnels serial over CAN, far from ideal but it gets the job done. Each board gets its own virtual serial port. Not very different from how USB serial does it.
We could make a better implementation that integrates better with how the klipper serial protocol works. But it works as is, I can't see any major issues with it. It currently has a separate daemon that does the CAN work (https://github.com/Delsian/CanSerial) that could be a part of klippy.
Klipper is very light on serial use and is quite latency and error tolerant. Each board uses peek ~30 kbits/s. I can easily run all my 5 prototypes on one 500kbit/s bus. I estimate that for a stable system you should not use more than 8 per 500kbit/s CAN bus. But you can have many busses per host (The CAN hats for the PI's are horrible for scaling, it's better to use USB dongles).
CAN, being a bus, makes it possible to sniff, analyze and inject traffic on the bus. As it is a strict priority bus it's easy to fill it to 75% with high prio junk trafic, or flood it with low prio traffic. I have had a lot of fun :)

[SteveJWallace]

The main issue I see is that the serial protocol itself doesn't fit can well. As an example, typically in can, collisions are detectable and less significant bits succeed atop higher bit commands. This means that cmd will always be heard. This is commonly used in embedded systems as a hard stop for everything.

…

On Wed, Jun 24, 2020, 9:43 PM bondus ***@***.***> wrote: Where are all the EEs when you need them? Hidden in some corporate basement! The current CAN implementation tunnels serial over CAN, far from ideal but it gets the job done. Each board gets its own virtual serial port. Not very different from how USB serial does it. We could make a better implementation that integrates better with how the klipper serial protocol works. But it works as is, I can't see any major issues with it. It currently has a separate daemon that does the CAN work ( https://github.com/Delsian/CanSerial) that could be a part of klippy. Klipper is very light on serial use and is quite latency and error tolerant. Each board uses peek ~30 kbits/s. I can easily run all my 5 prototypes on one 500kbit/s bus. I estimate that for a stable system you should not use more than 8 per 500kbit/s CAN bus. But you can have many busses per host (The CAN hats for the PI's are horrible for scaling, it's better to use USB dongles). CAN, being a bus, makes it possible to sniff, analyze and inject traffic on the bus. As it is a strict priority bus it's easy to fill it to 75% with high prio junk trafic, or flood it with low prio traffic. I have had a lot of fun :) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHE2SL236UCCUAMVXIWJALRYKTTNANCNFSM4ODQ7YLQ> .

[SteveJWallace]

Anyhow, if I can be of any use let me know. My c/c++ is rusty as heck. But I have lots of experience in troubleshooting rs-485 and Can.

…

On Wed, Jun 24, 2020, 9:43 PM bondus ***@***.***> wrote: Where are all the EEs when you need them? Hidden in some corporate basement! The current CAN implementation tunnels serial over CAN, far from ideal but it gets the job done. Each board gets its own virtual serial port. Not very different from how USB serial does it. We could make a better implementation that integrates better with how the klipper serial protocol works. But it works as is, I can't see any major issues with it. It currently has a separate daemon that does the CAN work ( https://github.com/Delsian/CanSerial) that could be a part of klippy. Klipper is very light on serial use and is quite latency and error tolerant. Each board uses peek ~30 kbits/s. I can easily run all my 5 prototypes on one 500kbit/s bus. I estimate that for a stable system you should not use more than 8 per 500kbit/s CAN bus. But you can have many busses per host (The CAN hats for the PI's are horrible for scaling, it's better to use USB dongles). CAN, being a bus, makes it possible to sniff, analyze and inject traffic on the bus. As it is a strict priority bus it's easy to fill it to 75% with high prio junk trafic, or flood it with low prio traffic. I have had a lot of fun :) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHE2SL236UCCUAMVXIWJALRYKTTNANCNFSM4ODQ7YLQ> .