Learning- How G-Code and Firmware Interact

[alankilian]

@jrcl

It's complicated and pretty difficult to answer all those questions through a text interface rather than through a couple-hour long discussion.

You can see the code here.
Some documentation on how things work is here.

Basically, the firmware is written in C++ and "consumes" GCODE and generates stepper motor control signals (as well and heater, fan, and lots of other control signals and reads inputs from temperature sensors, switches, pulse-generators, and other stuff.)

You can configure other axes using Gcode and Mcodes.
You can use the Reprap configurator for several different machine kinematics (organization of the mechanical joints and motors.)

It'll be quite a ride getting to know enough to be able to modify the firmware to add additional functions, but you'll get there.

[fcwilt]

@jrcl

Hi,

Here is the link to the site where you can find out the answers to most of your questions.

https://www.reprapfirmware.org/

The firmware that runs on the Duet hardware appears to be written in C++ but I have never delved into it. Others here have and have made their own modifications/additions to the firmware.

I don't use the Reprap Wizard. I started with a sample set of configuration files and using the Gcode Dictionary learned how to create configuration files from scratch.

You can establish additional axes using Gcode and control them with Gcode to a limited degree. But, as far as I know, to do anything during printing that is in sync with other axes is going to have to be done in firmware.

Good luck with your project.

Frederick

[JRCL]

@fcwilt When you say "establish additional axes using Gcode and control them with Gcode to a limited degree" do you mean with just manual modification of gcode from a printer slicer or entirely making your own command set to operate only once.

These additional axes shouldn't have to do anything during the actual printing, just after.

[JRCL]

@alankilian Thank you so much I'll make sure to start looking into all of these!

[fcwilt]

@jrcl said in Learning- How G-Code and Firmware Interact:

When you say "establish additional axes using Gcode and control them with Gcode to a limited degree" do you mean with just manual modification of gcode from a printer slicer or entirely making your own command set to operate only once.

These additional axes shouldn't have to do anything during the actual printing, just after.

That sort of thing you can do. For example, I retro-fitted one of my printers with a removable Z probe just to try it out. Because of the limited space on the printer I had to install a small stepper controlled linear guide (50 mm travel) to move a needed part into place as needed and out of the way as needed. Since it had nothing to do with printing I was able to create a pair of files with the need gcode commands to control the stepper motor as needed.

Frederick

[dc42]

@jrcl can you tell us more about what else you want the machine to do? Adding additional axes is easy using the M584 command, as long as all axes are expected to move in sync when multiple axes are moving at the same time.

[rjenkinsgb]

The firmware is a "G Code interpreter" that in principle reads a line at a time and performs whatever function or movement that line requires.

Re. other commands and axes;
You can have additional motors linked to extra "axis name" letters, that can be commanded to move when needed.

You can also have on/off switching outputs and access many other hardware functions on the Duet board, by commands in the G Code program.

If there you need complex combinations from a single instruction, you can define macros (G code subroutines) triggered by spare M codes or called by name.

For adding functions in during printing, look at the custom G Code sections available in such as Prusa Slicer.
You can have custom commands run at the start of the program, the end of the program, at any layer change, extruder change etc. etc.

And the Duet has a "Demon" facility, a file that can be auto executed at regular intervals to monitor or control additional hardware totally independently (within reason) while the printer is running.

If you give full details of what you are trying to achieve, there is a good chance it can be done just with the appropriate configuration of the machine and slicer.

[JRCL]

@dc42 @rjenkinsgb

In short, I'm attempting to operate a thermoform "onto" the print bed once the print is done. So once a print is done the print head moves out of the way and a heater heats up a thermoplastic sheet held by a carriage that moves parallel to the Z-Axis, via belt connected steppers, so the sheet can be pulled over the bed. Then the vacuum turns on. So in summary:

1. I need an additional axis to rotate the print head out of the way
2. I need an additional axis for the steppers driving the carriage, but moves linearly from the belts
3. I need to setup a PID controller for the additional heating element via a relay as I'm using a an 120VAC load with a 3-32VDC control signal. Thinking PWM pins or GPIO pins for this?
4. I need to control the vacuum, which I would like to just do with the GPIO pins

Thank you so much for your time and willingness to dive further into it with me!

[fcwilt]

@jrcl said in Learning- How G-Code and Firmware Interact:

1. I need an additional axis to rotate the print head out of the way

Would it not be enough to simply lower the bed far enough down to provide the clearance need to move the carriage into place over the model?

2. I need an additional axis for the steppers driving the carriage, but moves linearly from the belts

That's easy.

3. I need to setup a PID controller for the additional heating element via a relay as I'm using a an 120VAC load with a 3-32VDC control signal. Thinking PWM pins or GPIO pins for this?

That's easy.

4. I need to control the vacuum, which I would like to just do with the GPIO pins

That's easy.

Frederick

[JRCL]

@fcwilt Unfortunately due to the dynamics of the machine and some other physical constraints I have to rotate it entirely away.

Happy to hear everything else is easy to do. I assume you mean routinely and not just adding a bunch of raw g-code to the end of the sliced model file.

[engikeneer]

@jrcl well you'll need gcode lines in your config to define your motors, axes, heaters etc (all standard but you'll just have more of them). You'll then need some extra gcode to run at the end of a print file do the motions you require (e.g. rotate axis A by 90deg, move axis B 100mm etc.) That could all be in a macro on the printer, then the print file just needs to call that macro e.g. M98 P"doSomeCleverStuff.g"

[fcwilt]

@jrcl said in Learning- How G-Code and Firmware Interact:

@fcwilt Unfortunately due to the dynamics of the machine and some other physical constraints I have to rotate it entirely away.

That is going to make it hard and likely expensive. How about a setup where the bed is moved to a different location out from under the print head? That's easy.

Happy to hear everything else is easy to do. I assume you mean routinely and not just adding a bunch of raw g-code to the end of the sliced model file.

Slicers have the ability to call custom gcode on the printer at the start of the print, at the end of the printer and during certain events during the print.

Frederick

[rjenkinsgb]

@jrcl said in Learning- How G-Code and Firmware Interact:

In short, I'm attempting to operate a thermoform "onto" the print bed once the print is done. So once a print is done the print head moves out of the way and a heater heats up a thermoplastic sheet held by a carriage that moves parallel to the Z-Axis, via belt connected steppers, so the sheet can be pulled over the bed. Then the vacuum turns on. So in summary:

As far as the controller & firmware etc., everything you want to do can be done just with correct configuration and adding a macro to run the extra mechanics; or add the full code to the slicer end code, either way.

Rotating the head away while still maintaining full accuracy seems difficult though; using a larger frame so the axes can move clear of the required area is likely cheaper.

The only high-accuracy possibility I can think of could be to use an E3D toolchanger system, with a hinge and servo added above the tool attachment point so when the tool is unclamped it can be swivelled up over the carriage, rather than left in a static carrier.

Still complex and expensive, possibly more so than just longer axis rails to move a normal head clear.

All the other motions are straightforward and controllable, with pretty much off-the-shelf mechanical parts.