Cannot Find a way to contact, author #4
Comments
|
You found a way. It's improved now |
|
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>
.
|
|
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. |
|
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>
.
|
|
Where are all the EEs when you need them? Hidden in some corporate basement! |
|
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>
.
|
|
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>
.
|
There is no email or other way to contact the author.
The text was updated successfully, but these errors were encountered: