Pacemaker
Posted by frankvdh
As per this message in another thread, I'll start a new topic for Pacemaker discussion
In reply to things above:
By "Bed detection" I mean a Z-probe of some kind to find the height of the nozzle above the bed.
I agree that KISS is good, but disagree that that means the same language should be used on both client and server. Limitations on one platform shouldn't be limitations on another. Good documentation of the protocol between the two systems is what's needed.
I agree that we don't need a Python/C/C++/Java flamewar. Or an IOS/Linux/MacOS/Android/iOS flamewar. Java doesn't mean it has to run on Android. There's lots of flavours of Java; when I did some Android programming a few years ago, I found the UI to be quite different from desktops (e.g. JavaFX).
I use Octopi to run my printer. However, I still find the LCD useful for displaying nozzle height, temperature, X,Y positions, etc. No big deal though, if you have a RPi with a display (I don't (yet)).
I do think that Gcode & STL are now becoming limiting factors for 3D-printing, so welcome moves away from them.
Quote
JustAnotherOne
@frankvdh there is some documentation
For discussion we can have that here (probably better in a new Thread) or in github Issues or you can private mail me.
What Pacemaker needs right now is developers.(See "not yet" below) So a bit of reading the code can not be avoided.
Quote
frankvdh
Can I install the client on my Delta (Arduino Mega2560, I think), install the host on my Pi3, and start printing stuff?
Delta printers are not supported yet. But the host can run on a Pi3 just fine. Minnow and pmc can both run on a Atmega2560.
Quote
frankvdh
Does it print better or faster than my existing Repetier firmware?
I did not do comparisons like this. Right now the movement planning (on the host) is also not yet optimized for speed.
Quote
frankvdh
Does it do fancy stuff like heated bed temperature control, bed detection, bed levelling, LCD display, multiple extruders?
Quote
frankvdh
heated bed temperature control,
yes
Quote
frankvdh
bed detection,
What should that be ?
Quote
frankvdh
bed levelling,
not yet.
Quote
frankvdh
LCD display,
As with klipper/klippy having a display on the client does not make much sense. But you can attach a LCD (HDMI) to the RaspberryPi. That will then be much fancier than those displays usually connected to an Arduino2560,...
Quote
frankvdh
multiple extruders?
not yet implemented, but would be a host only extension.
@markodorsch I don't understand your reasoning behind this:
Quote
markodorsch
So the KISS-Principle do not allow anything else then C/C++ for the host software.
I would think that compiling source code only once and then having a binary that runs on all hosts is easier than needing different compilers for each host and needing to compile for each host is more complicated. Can you explain?
Quote
markodorsch
But there is no pure C/C++ software for the host, so Python may be the next best choice
Java can be compiled to pure C++ by gcj. gcj is part of the Gnu Compiler Collection(gcc). You can think of Java a as a subset of C++.
Quote
markodorsch
Only the usage of Python and the DECL_CTR is something i don't like in Klippy, but there is always something to complain about.
I don't like the complete lack of Error handling in Klippy/Klipper and doing stuff like PID on the host. But you are right, "there is always something to complain about."
I again don't get the reason for this statement:
Quote
markodorsch
Pacemaker is written in Java, so the main target should be an android app.
If someone wants to reuse their old phone or tablet in a printer then they can do what you suggest. But that is not my plan. Again Developers and pull-request are welcome.
Pacemaker also does not want to replace Octoprint. The pacemaker host, as Klipper, accepts G-Code.
In reply to things above:
By "Bed detection" I mean a Z-probe of some kind to find the height of the nozzle above the bed.
I agree that KISS is good, but disagree that that means the same language should be used on both client and server. Limitations on one platform shouldn't be limitations on another. Good documentation of the protocol between the two systems is what's needed.
I agree that we don't need a Python/C/C++/Java flamewar. Or an IOS/Linux/MacOS/Android/iOS flamewar. Java doesn't mean it has to run on Android. There's lots of flavours of Java; when I did some Android programming a few years ago, I found the UI to be quite different from desktops (e.g. JavaFX).
I use Octopi to run my printer. However, I still find the LCD useful for displaying nozzle height, temperature, X,Y positions, etc. No big deal though, if you have a RPi with a display (I don't (yet)).
I do think that Gcode & STL are now becoming limiting factors for 3D-printing, so welcome moves away from them.
|
Re: Pacemaker May 30, 2017 06:55PM |
Registered: 11 years ago Posts: 126 |
For those that did not follow the other thread a short intro might help:
Pacemaker is the Idea of splitting all the things a firmware does into a host and a client part. The Host can run on a Raspberry Pi or a PC Laptop whatever. The client runs on the printer control board. The client can handle the time critical stuff (making steps at the exact right moment in time) and the host can use the higher performance to do acceleration and speed calculations.
This pacemaker system fits into the normal tools as the host reads in G-Code and the client can control normal 3d Printer electronics (AVR or 32bit processor, Steppers, Heaters, Temperature sensors,..)
My implementation of a Host and client are open source. Robert (buildrob) helped defining the protocol between host and client and came up with his own Marlin based client.
We started this at a time when more and more feature requests have been declined due to lack of cpu performance. We saw this as a option to get more performance into the system and a chance to fix some of the issues with the current state of 3d printing firmware.
It was always meant as an open system for everyone to come in and contribute I would therefore be very happy to see more people engaging in this idear so that we cn together move this forward.
Back to business:
Ah ok. Then the answer is "not yet". For me usually Bed detection and bed leveling are the same thing. That caused my confusion.
With this distinction one could say that "Bed Detection" is supported in the client. The client has support for end stops. As the host is the one who issues the moves for bed detection all the client has to do is to detect a triggered switch. And that it can already do ;-)
I think that "Good documentation of the protocol between the two systems" is an especially strong point of Pacemaker. The protocol specification is here Both Robert and I implemented Client against this documentation and the communication with the host works without issues. The Protocol specifies everything down to the last bit. It also provides a good abstraction level and is open to extension.
For clarity I would here differentiate between a "status display" and a "menu display".
A menu display like the one implemented in marlin witch allows to change settings and to start action makes in a system that is split between host and client no sense on the client side. This would mean that the host would need to read information from the client of what the user did in the menu to then decide what to do and to instruct the client accordingly. For me that makes no sense.
A status display would be a display that just display the current state (Nozzle position, temperatures,..) Is something that can help in a situation where the host has no display. The data needed for a status display are at least in parts already known on the client. Other information can easily be send to the client. So that would make sense.
STL is easy to parse but has some issues (water tight, orientation of triangles, dual extrusion) It also makes round surfaces difficult. That's also part of the reason why nobody uses arcs (G3 G4). But this is mainly a issue for slicers and not for the firmware.
Coming up with new codes all the time and to deal with different implementations of the same g-Code in the different firmwares is an issue. There have been ideas in the past to come up with new protocols. But again this also needs slicers that slice models into this new format. With the higher levels of the firmware on the host this might be a good starting point for experiments. And for functionality that does not involve the slicer enhancements are definitely possible based on the pacemaker protocol.
The pacemaker system gives us the flexibility to try different things. Maybe the current split of functionality between octoprint - slicer and pacemaker host is not the best possible. Maybe functionality could better perform if it would move from one to the other. With all of them on the same platform these changes would be possible.
But that are ideas that are far in the future. The current focus has to be to change all those "not yet" s into yes.
Pacemaker is the Idea of splitting all the things a firmware does into a host and a client part. The Host can run on a Raspberry Pi or a PC Laptop whatever. The client runs on the printer control board. The client can handle the time critical stuff (making steps at the exact right moment in time) and the host can use the higher performance to do acceleration and speed calculations.
This pacemaker system fits into the normal tools as the host reads in G-Code and the client can control normal 3d Printer electronics (AVR or 32bit processor, Steppers, Heaters, Temperature sensors,..)
My implementation of a Host and client are open source. Robert (buildrob) helped defining the protocol between host and client and came up with his own Marlin based client.
We started this at a time when more and more feature requests have been declined due to lack of cpu performance. We saw this as a option to get more performance into the system and a chance to fix some of the issues with the current state of 3d printing firmware.
It was always meant as an open system for everyone to come in and contribute I would therefore be very happy to see more people engaging in this idear so that we cn together move this forward.
Back to business:
Quote
frankvdh
By "Bed detection" I mean a Z-probe of some kind to find the height of the nozzle above the bed.
Ah ok. Then the answer is "not yet". For me usually Bed detection and bed leveling are the same thing. That caused my confusion.
With this distinction one could say that "Bed Detection" is supported in the client. The client has support for end stops. As the host is the one who issues the moves for bed detection all the client has to do is to detect a triggered switch. And that it can already do ;-)
Quote
frankvdh
I agree that KISS is good, but disagree that that means the same language should be used on both client and server. Limitations on one platform shouldn't be limitations on another. Good documentation of the protocol between the two systems is what's needed.
I think that "Good documentation of the protocol between the two systems" is an especially strong point of Pacemaker. The protocol specification is here Both Robert and I implemented Client against this documentation and the communication with the host works without issues. The Protocol specifies everything down to the last bit. It also provides a good abstraction level and is open to extension.
Quote
frankvdh
I use Octopi to run my printer. However, I still find the LCD useful for displaying nozzle height, temperature, X,Y positions, etc. No big deal though, if you have a RPi with a display (I don't (yet)).
For clarity I would here differentiate between a "status display" and a "menu display".
A menu display like the one implemented in marlin witch allows to change settings and to start action makes in a system that is split between host and client no sense on the client side. This would mean that the host would need to read information from the client of what the user did in the menu to then decide what to do and to instruct the client accordingly. For me that makes no sense.
A status display would be a display that just display the current state (Nozzle position, temperatures,..) Is something that can help in a situation where the host has no display. The data needed for a status display are at least in parts already known on the client. Other information can easily be send to the client. So that would make sense.
Quote
frankvdh
I do think that Gcode & STL are now becoming limiting factors for 3D-printing, so welcome moves away from them.
STL is easy to parse but has some issues (water tight, orientation of triangles, dual extrusion) It also makes round surfaces difficult. That's also part of the reason why nobody uses arcs (G3 G4). But this is mainly a issue for slicers and not for the firmware.
Coming up with new codes all the time and to deal with different implementations of the same g-Code in the different firmwares is an issue. There have been ideas in the past to come up with new protocols. But again this also needs slicers that slice models into this new format. With the higher levels of the firmware on the host this might be a good starting point for experiments. And for functionality that does not involve the slicer enhancements are definitely possible based on the pacemaker protocol.
The pacemaker system gives us the flexibility to try different things. Maybe the current split of functionality between octoprint - slicer and pacemaker host is not the best possible. Maybe functionality could better perform if it would move from one to the other. With all of them on the same platform these changes would be possible.
But that are ideas that are far in the future. The current focus has to be to change all those "not yet" s into yes.
Sorry, only registered users may post in this forum.