M98 directory

DonStauffer

@T3P3Tony I can understand if the path of the currently running macro isn't already stored it would take a byte for every character plus a little overhead to save it. That could be substantial on a Duet2 especially. But if it's already there, I think very little memory would be needed.

Presumably, a pointer to the string containing the filespec for a nested macro call gets passed to a function to begin reading the file. I'm imagining in the calling scope that string wouldn't get freed until the nested call returns, though it's certainly possible it's freed sooner. But if it's not freed until after return, and there's a pointer to it, storing that pointer would only take a few bytes.

oliof

it would be a couple bytes per nested call, and since this feature would most likely be used by people doing more complex macros, it would be more memory than just a few bytes sooner rather than later...

DonStauffer

@T3P3Tony For the heck of it, I looked at the code on GitHub. Hard to get a handle on it looking at it briefly, so I may be way off base, but a question:

Does the GCodeBuffer object for the M98 continue to live until the macro is fully done executing? It seems like it would, and it's the GetString method that returns the filename (which seems to actually be a filespec), so that makes me hopeful.

I'm curious if I'm anywhere in the right vicinity.

PS: I love C++!

DonStauffer

@oliof Yes, that's true. Still, I wonder if a pointer may already be stored indirectly, in the form of a pointer to an object which can return the pointer. Maybe. IDK, I could be way off base, but if a pointer is already sitting there ...

T3P3Tony

@DonStauffer that's a question for @dc42 or @chrishamm .

dc42

@DonStauffer RRF has no concept of a current directory. For every command that takes a filename argument there is a default directory that is used if the specified filename does not include an a absolute path.

Currently, RRF does not remember the names of macro files currently executing. I am planning to add this (except on Duet 2 because of memory constraints) in order that error messages can include the filename. So in principle we could have M98 accept a relative path when M98 is invoked from another macro file. However, there is another issue with using "./" as a prefix for this, which is that using that prefix is the same as not using it. That is the convention for path names and I am fairly sure is how the FatFs filesystem used by RRF behaves. I would not want to deviate from that behaviour.

DonStauffer

@dc42 The ability to change that default directory might be just as good.

Unfortunately my Railcore has a Duet2 (with Duex & PanelDue). I've thought about replacing it with a Duet3 but I don't have time to evaluate form factor and connections to be sure I could just drop it in my Railcore.

oliof

@DonStauffer two Duet 3 mini would be drop in replacements for Duet2 and Duex foot print wise, running one of the minis as CAN expansion board. Whether that has all the IO you need depends on your machine specifics.

DonStauffer

@oliof This is up to date for my dual-extruder Railcore, except that since then I've been playing with the LED output and the I2C output, and I have in mind adding a thermistor to measure ambient temperature:

Ports are listed in order from left to right and top to bottom.
Duet 2 WiFi

Power (Middle Right)
USB (Middle Left)
Stepper Motors (Top Right)
Drive 4 E1 MOTOR Secondary extruder
Drive 3 E0 MOTOR Primary extruder
Drive 0 X MOTOR Back XY stepper
Drive 1 Y MOTOR Front XY stepper
Drive 2 Z MOTOR (unused)
End Stops (Middle)
E1 STOP e1stop filament sensor
E0 STOP e0stop filament sensor
X STOP xstop Build area Left Rear
Y STOP ystop On carriage
Z STOP (unused)
Heaters (Top Left, Bottom Right)
E1 HEATER e1heat Secondary hot end
E0 HEATER e0heat Primary hot end
HEATED BED bedheat Bed heater MOSFET control

Thermistors (Middle Left, Bottom Right)
THERMISTOR2 E1 e1temp Secondary Hot End
THERMISTOR1 E0 e0temp Primary Hot End
THERMISTOR0 BED bedtemp Bed
Fans (Middle Right)
PWM:
FAN2 (unused)
FAN1 fan1 Secondary Part Fan
FAN0 fan0 Primary Part Fan
Always On:
Secondary Heat Sink Fan
Primary Heat Sink Fan
Z Probe (Bottom Left)
Z PROBE zprobe.in BLTouch

Duex

Power (Middle Right)
Stepper Motors (Bottom)
Drive 9 E6 MOTOR (unused)
Drive 8 E5 MOTOR (unused)
Drive 7 E4 MOTOR Right Z stepper
Drive 6 E3 MOTOR Back Left Z stepper
Drive 5 E2 MOTOR Front Left Z stepper
Servos (Lower Left)
PWM5 E6_PWM (unused)
PWM4 E5_PWM (unused)
PWM3 E4_PWM (unused)
PWM2 E3_PWM duex.pwm2 LED lights (white, not NeoPixels)
PWM1 E2_PWM duex.pwm1 BLTouch
End Stops (Upper Center)
E6 STOP E1 STOP (unused)
E5 STOP E0 STOP (unused)
E4 STOP X STOP (unused)
E3 STOP Y STOP (unused)
E2 STOP Z STOP (unused)
Heaters (Upper Right)
E2 HEATER (unused)
E3 HEATER LED lights wiring
E4 HEATER (unused)
E5 HEATER (unused)
E6 HEATER (unused)
Thermistors (Middle)
E4 THERMISTOR5 (unused)
E3 THERMISTOR4 (unused)
E2 THERMISTOR3 (unused)
E6 THERMISTOR7 (unused)
E5 THERMISTOR6 (unused)
Fans (Upper Left)
FAN8 (unused)
FAN7 (unused)
FAN6 (unused)
FAN5 (unused)
FAN4 duex.fan4 (unused)
FAN3 duex.fan3 Case fan

droftarts

@DonStauffer I think there's enough drivers and I/O on a Duet 3 Mini 5+ with Duet 3 expansion Mini 2+ (to give 7 motor drivers) to drive your setup.

Ian