Set Gcode control from <printer name>.machine

[kloknibor]

Since some printer require different Gcode it may be nice to add an Gcodecontrol file from .machine file. I know there are already 2 other Gcodecontrol classes but I don't know if they can be easily selected for an specific printer. I couldn't find it at least. Would this be possible?

Thanks!

[WesGilster]

That's already available here in "DriverType". Just name your new driver the same as below except you can change the bolded part.

org.area515.resinprinter.gcode.eGENERICGCodeControl

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MachineConfig FileVersion="0">
    <PlatformXSize>134.0</PlatformXSize>
    <PlatformYSize>75.0</PlatformYSize>
    <PlatformZSize>185.0</PlatformZSize>
    <MaxXFeedRate>0</MaxXFeedRate>
    <MaxYFeedRate>0</MaxYFeedRate>
    <MaxZFeedRate>0</MaxZFeedRate>
    <XRenderSize>1824</XRenderSize>
    <YRenderSize>984</YRenderSize>
    <MotorsDriverConfig>
        <DriverType>eGENERIC</DriverType>

[WesGilster]

Although it seems strange that your printer would require a whole different driver.

[kloknibor]

Yes they use their own firmware... and hardware... So indeed it's strange... I'll set it thanks :)!

[WesGilster]

Your class should probably look something like the following. No need to re-implement all of the methods that didn't change.

public class PhotocentricGCodeControl {
    public PhotocentricGCodeControl(Printer printer) {
        super(printer);
    }

    public String executeMoveZ(double dist) {
        return sendGcode(String.format("G1 Z%1.3f F100.0\r\n", dist));
    }

    public String executeZHome() {
        return sendGcode("G28\r\n");
    }
}

[WesGilster]

Sorry, I'll post on your pr instead. Thanks for taking a look at this.

[kloknibor]

Do I need to include the normal gcodecontrol like you do in Egeneric? And this will overrulle it or...?

[jmkao]

Perhaps as a future enhancement we could parameterize the G-code into the machine configuration. In particular, the F feed rate parameter can vary from machine to machine by small amounts.

For instance, even on my one machine, depending on which stepper driver I have installed (A4988 or DRV8825) and what the current limit potentiometer is set to, there can be a particularly nasty Z-axis resonance at certain speeds. It would be nice to change the feed rates to avoid the resonating speed w/o having to compile a custom G-code driver...

[WesGilster]

@kloknibor Your right, I forgot to extend the previous class, just had some time before work to fix, but I didn't quite get it right.

@jmkao Yeah, I actually agree. Were you thinking of a scripted calculator? Keep in mind that this driver is really only used for the purposes of the screen controls. Still, I agree it should work with the screen and it doesn't really need to be done for the future. I can hook that in pretty easily.

[jmkao]

Thinking about this in terms of screen controls, one way that might work would be to have a section in the machine dedicated to properties about the machine controls, which might even allow config-based addition of custom buttons, so that not every small machine-specific UI change would require one to fork a whole set of resources. Maybe something like an XML section like:

<controls>
  <showX>true</showX>
  <showY>true</showY>
  <showZ>true</showZ>
  <defaultGCode>
    <moveX>G1 X%1.3f F900</moveX>
    <moveY>G1 Y%1.3f F900</moveX>
    <moveZ>G1 Z%1.3f F100</moveZ>
    <homeX>G28 X</homeX>
    <homeY>G28 Y</homeY>
    <homeZ>G28 Z</homeZ>
    <homeAll>G28</homeAll>
    <modeAbsolute>G90</modeAbsolute>
    <modeRelative>G91</modeRelative>
    <motorsOn>M17</motorsOn>
    <motorsOff>M18</motorsOff>
  </defaultGCode>
  <customButtons>
    <!-- Some kind of default, unconfigurable, grid layout for easy addition of small stuff -->
    <button>
      <label>Show Position</label>
      <gcode>M114</gcode>
    </button>
  </customButtons>
</controls>

There would still be a question of whether or not we should have each field have presumed, field-specific input (e.g. for moveX,Y,Z) or if the values should be templated, and how we want to interpret escape characters, like do we make people do XML entities like for a CRLF, or if we allow them to use \r\n and interpret it ourselves.

[WesGilster]

I like where this is going, but eventually this theory evolves into a very tricky place. You get into this situation where there is really no point in building: header/pre-slice/post-slice/footer gcode templates anymore. Instead, you have a set of abstracted print concepts that should be sent to all printers. It's very close to what our abstracted printing already does, but instead it's executed at a very fine grain level: MotorsOn HomeZ Show image moveZ 2 moveZ 1 repeat...

Now maybe your suggesting that these functions should only be used at the screen level. If so, it's quite a bit of work for some screen buttons. Eventually we would need it to create a very professional look and feel, but as you said, this is probably better for the future.

As to escape chars, CRLF and entities, let's leave all of that to our XML Marshaller and not get into custom char sequences. These issues are a solved problem in today's XML parsers and it's not a place where we want to go. Also, Freemarker has it's own escape sequences that should solve any advanced issue we have to deal with I'll bet we could even push binary out to the printers with FreeMarker if we needed.

I also suggest that we rename these from from gcode to printerMessage or something like that. Maybe Sedgwick is the only printer of it's kind, but I can see how other printers may not want to use gcode.

[jmkao]

Yeah, my idea is purely based on the control screen, to try to bridge the gap between the most common machine specific requirements and the more exotic ones that would requiring forking all of the resources.