IF..THEN Statements in GCode???

[Kurt The 3D Printer GUY!]

I just learned about this recently - and was VERY Surprised!

Some years ago, as I was digging deep into 3D Printing - including working at SD3D in SD - this kind of GCode capability would have been a Damn Game changer for what we were doing at SD3D. 

So, yeah - I only just learned that this is a NEW Thing with the Duet Firmware!

Are other folks aware of this???

A little more details - just a Tad...

So, one can do an If...Then type looping structure. For instance, one can do something such that the system can do some looping structure - and getting feedback via the IF then statement for Nozzle Temps. And, I believe - in the GCode - it can also do WHILE Statements.

I find it exciting - because my own background in programming. 

Anyway - I'm REALLY Curious to know if anyone else in this group has experience with this new special kind of GCode - and I'd be curious to know how folks might be implementing it. 

-K

[Ed Street]

Well YES, I do ;) However, it's not Marlin based, which is grossly crippled in this arena, but it is Klipper, which does *NOT* pose these problems; why not?   Simply put it is written in Python. Second, the code is not running on the controller card but on the host card, which is often a Raspberry PI. 

Here is a section of my code that is in use.

##
## This G-code will allow you to probe cold, but will also prevent you from probing with a nozzle at printing temperature
## (to try to preserve your build surface).
##


activate_gcode:
 ## Tap temp probing
 {% set PROBE_TEMP = 150 %}
    {% set MAX_TEMP = PROBE_TEMP + 5 %}
    {% set ACTUAL_TEMP = printer.extruder.temperature %}
    {% set TARGET_TEMP = printer.extruder.target %}

    {% if TARGET_TEMP > PROBE_TEMP %}
        { action_respond_info('Extruder temperature target of %.1fC is too high, lowering to %.1fC' % (TARGET_TEMP, PROBE_TEMP)) }
        M109 S{ PROBE_TEMP }
    {% else %}
        # Temperature target is already low enough, but nozzle may still be too hot.
        {% if ACTUAL_TEMP > MAX_TEMP %}
            { action_respond_info('Extruder temperature %.1fC is still too high, waiting until below %.1fC' % (ACTUAL_TEMP, MAX_TEMP)) }
            TEMPERATURE_WAIT SENSOR=extruder MAXIMUM={ MAX_TEMP }
        {% endif %}
    {% endif %}

This code is called jinja2.

Here is a for loop example.

 ## Wipe nozzle
 {% for wipes in range(1, (wipe_qty + 1)) %}
   G1 X{start_x + wipe_dist} F{wipe_spd}
   G1 X{start_x} F{wipe_spd}
 {% endfor %}

We prefer our controller cards to print only.  Everything else is left up to a beefier processor; we can call Python scrips, Bash/C/SH/ASH/etc. Shell scripts.  

When your controller card is doing anything besides printing, there is a serious problem at play.

[Kurt The 3D Printer GUY!]

I will admit - code like this running on a unit that is not the controller card does make sense. 

Although, for the future of 3D Printing - I think the controller card in the printer SHOULD be powerful enough to be fully self-contained and NOT require a secondary controller unit like a Pi. Heck, what might make sense is to have maybe a secondary controller Chip on the main board - for extra processing power. Similar to a Quad-Core chip, that essentially has Four core processing units. And, thus - if you dedicate a program to run on 2 of those cores - say the main 3DP Processing unit - then the Other Two cores could be used similar to how we use a Pi to control a printer!

So - this code below is called Jinja2?  Yup - cause you posted about this - I started a Mini Dive down the Jinja2 rabbit hole. Cool logo:

Will admit - the dive was a bit confusing - since, on this webpage ( Jinja — Jinja Documentation (2.10.x) (palletsprojects.com) ) - it states "templating language for Python" - which I found to be confusing terminology. I'm indeed familiar with Frameworks. It's been a little while since I was last dabbling in Python at Essentium - but, at the time - I think the framework I was using was maybe called Spider. But, it seems - that is NOT what Jinja is. However, on this webpage ( Introduction — Jinja Documentation (2.10.x) (palletsprojects.com) ) - it finally mentions that it "is a library for Python" - which makes sense. Since, I know that Python is really all about Libraries - and that's what makes it so powerful. And, when I was doing the Lazarus project for Essentium, I actually tried not One but Two different UI libraries. 

So, it makes sense that Jinja is a library.

I may have to dabble more and maybe play around with Jinja at some point in the near future...

-K

[Ed Street]

Here's the deal, Kurt. The 'controller' is all about managing the hardware. This board typically houses stepper drivers, temp chips, MOSFETs, and other components, with the controller card CPU taking care of the associated processing. However, it's crucial to understand that the controller isn't designed or set up to handle complex mathematical operations or algorithms. Essentially, this is nothing more than a sorting system that sends each task to its proper place to get handled accordingly.

To tackle the other tasks, you'll need to shift the workload to a more capable processing unit.  This is the 'HOST' job.  From here, you can embed objects much like we did with C++ objects, create a vast library of tasks, and perfect everyone for print quality and store that in a database. Then, when the slicer needs a task done, it just picks objects and puts them together.

8-bit, 16-bit, and 32-bit boards have been dying by the droves in favor of 64-bit boards that can handle the loads better, faster, and with less strain.  Older systems still in use are the problem and it is a very big problem

On the Klipper side of things, Jinja2 is a fascinating scripting language setup for Python, and yes, indeed, Klipper is based on Python.  Here are two links that provide a comprehensive understanding of the range and depth of what Klipper can do, further reinforcing our recommendation.  So when they said recently, "have to learn g-code," My brain immediately did s/gcode/macros because under klipper, we use macros, functions that can call other functions, yes, even gcode.  We can even hijack 'gcodes' and do other things in place of, in addition to. This is a good and proper 'cancel print' macro used in most machines.

https://klipper.discourse.group/t/macro-creation-tutorial/30/4

and 

https://www.klipper3d.org/Config_Reference.html

Also, I have to say Klipper has many misconceptions about it.  It does not surpass hardware limitations, i.e., as the podcast likes to point out with Klipper, the Creality guide rods.

Also worth noting here is that the Bambu machines, notably the X1C, have TWO control boards, one for printing (MP board) and one for processing (AP Board). While it is printing, you can REBOOT the AP board without losing the print.

[Alan B]

It's an excellent division of labor to split the real time controls from the networking and high level calculations. More and more printer control boards have dual processors. One would think that core management could handle it but there are many other aspects of I/O and performance behavior that differentiate MCU from MPU architectures. Chips are cheap, and software complexity and bugs are expensive, so use the hardware. It is also useful for security to have physical separation. You don't want a network hack directly interfering with timers that control PIDs and shut down heaters.

32 bits is plenty for networking and trajectory calculations, 4 GB of address space is more than adequate. 32 bit Pi's are idling while doing these tasks, 64 bits is just silly for this. It makes programs larger and wastes time for programs that don't benefit from the largesse.

[Kurt The 3D Printer GUY!]

Hey Ed & Alan - thanks for your feedback, as this does make for an interesting discussion!!!

-K

[Ed Street]

It is not so much that 32-bit or even 64-bit is needed for whatever task. It is more about manufacturing methods, materials, and some topics that are never discussed, such as the bus paths between components and is the USB is hooked up properly and doing 3.0 speed or is it a hacked bastardized version of RS-232 over USB (sadly most falls in this latter group)

Yes, the Division of Labor is very good, to call it.  The dual board, however, can be very problematic; if it is not designed properly, it can and WILL cause problems with the other controller.  The end goal is to not disrupt the print operation with added bulk non-essential things which separation becomes a must.  Can it be done? Yes, it can.  Will it be done badly?  Yes, yes, indeed, look at the state of USB connections today for how bad it can be.

[Kurt The 3D Printer GUY!]

Honestly - I didn't know there were so many problems with USB implementations!

Which makes for an interesting point. Why? Because, in the early days of desktop 3D Printing - it was not uncommon for folks to run print jobs by being to the 3DP via a USB connection. And, folks would Demand that's a Bad idea - as I believe even Andy covered that issue a number of times in the Podcast - or, at least he did on the older forums. Then, earlier this spring - I had an issue where I wanted to control my Ender - but, did Not have a mini-SD card handy. And, it was suggested I run the print job tethered by USB. And, I did find that I could do it - but, in the end, I didn't actually run a print job via the USB technique...

-K

[3D Printing Tips and Tricks]

Yah, we talked about usb issues years back before real Engineers were involved in designing controller boards. A usb port does not necessarily mean the board designers are complying with all of the ieee standards. Unfortunately it still doesn’t. Full ieee usb implementation is more than the hw or the voltage, it’s also the method of data parsing as well as integrity checks such as checksums. USB is designed to be an interface from a complete system out to another complete system. It’s not meant to be used in the same way as a data path within a system as in databuses.

Returning to the OP…

Running gcode that uses if then statements seriously bogs down a controller board. If your running a distributed system like Klipper or like my Raise3d N2 or a server than you want all conditional logic performed the re before the gcode is sent to the controller board otherwise you’ll see the printer stopping and doing prolonged pauses.

[Scott Hess]

I get the issues with USB, but ... in a consumer setting I'm not sure there's a strong alternative.  I've been pretty impressed with how far afield people manage to get with CANBUS installs, a lot of people just aren't qualified to muck around in that.  UART isn't much different.  USB lets a lot of participants at the technical margins participate who otherwise would be kind of lost.  It would be nice to have something better, heck just improving the physical connection to allow bolting it down, but I don't see vendors coming together in that way.

-scott

--
You received this message because you are subscribed to the Google Groups "3D Printing Tips and Tricks" group.
To unsubscribe from this group and stop receiving emails from it, send an email to 3d-printing-tips--...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/3d-printing-tips--tricks/f6b8cd25-596a-41cf-ab9b-66ce1cd28af1n%40googlegroups.com.