Page 1 of 1
Posted: Fri Mar 02, 2018 1:28 pm
Do the ideaMaker settings or touch screen settings take precedence when printing?
So, for example if I set the Step-E size in ideaMaker to one value and I set it to a different value via the touch screen, which value is used?
Re: Settings Precedence
Posted: Fri Mar 02, 2018 2:02 pm
Since you can change e-steps only before printing, the e-steps set in the g-code will override the preset of the machine.
Values which are changeable during printing will override the settings in the gcode.
Re: Settings Precedence
Posted: Fri Mar 02, 2018 2:09 pm
Let's go over basic system operation first so you really understand this instead of guessing.
When you turn on the printer, the 24V power supply sends power to both the motion control board running Marlin firmware, and to the front panel LCD housing to the delay timer board which waits a few seconds and then shorts the power on button contacts on the pcduino board to tell it to turn on. This is because the pcDuino is battery backed, so while it gets 24V to "power" it and charge the battery, simply turning on 24V does not natively make it turn on and wake up- hence the external delay timer board.
Next, the Marlin motion board boots from flash and first runs the bootloader code for a short time period to allow flashing and updating of firmware, then after that times out, then the main firmware as you know it based on Marlin code runs. As part of any running microcontroller application the actual running is done in the small amount of RAM contained inside the microcontroller. So the default firmware "hard coded" values are loaded from firmware into active memory and this is the settings used at the point in time. In other words, if it reads a line of gcode, it's going to use the default value stored in the original Marlin firmware (I forget the exact stock value, 96 steps per mm for E?).
Now, at the same time from turn on, the pcDuino front panel Linux computer booted and if and ONLY if it's running a recent LCD firmware touch update that included the new function of being able to set steps per mm, and that value is changed from default, then it sends the gcode command over the USB cable between the front panel and motion board running marlin and tells it to change the current active value for steps per mm on the axis that was changed from default. Example again, here is if you change in in the LCD menu under hardware, say E from the default of 96 to the required 415 steps per mm for a Bondtech BMG based extruder, then just after booting, the front panel sends a gcode command of M92 E415 per gcode standards to tell Marlin firmware actually running the printer to update in active memory only (because the firmware defaults are "hard coded" and not changeable by gcode command).
Net effect to the user- the default was changed to the new value the instant the machine fully booted.
Now, if you include an M92 in your printing gcode file- then because that was the most recent command sent, it then is now the active function.
But there is a giant caveat here!!! If in Ideamaker, you change steps per mm in the "Printer Settings" from default, then it appends the M92 command to every print file produced using that machine setting. But again, ONLY if the setting is changed from default.
If you manually go in and edit the starting gcode script elsewhere in the profile and manually add M92, this adds it as part of the gcode script to every print.
Where this can get wonky. If you change it in "Printer Settings" and you change it in the starting gcode sequence, then there will be 2 M92 commands in the final gcode print file. I'm not 100% sure on order of which shows first.
The RULE is, the LAST gcode command sent regarding M92 is then the active setting used for all commands following until another M92 command is sent or, if the motion board resets for any reason, it reverts back to the OEM firmware steps per mm (96 if running stock firmware).
Re: Settings Precedence
Posted: Fri Mar 02, 2018 2:27 pm
What we do not 100% know:
We have asked the exact procedure that happens when the LCD system has an alternate steps per mm setting in hardware.
We KNOW it sends the M92 at startup.
We assume (and it's a reasonable assumption) the Marlin motion board does not accidentally get reset and thus revert back to defaults (remember, you might have booted the printer days ago and left it on all this time). The logic here is a reboot of the Marlin motion control board would trigger an error to the front panel as it went through the booting process. Again, in theory, we think this is a checked state where if the board reboots, the other board sees that and errors.
We do not think but also do not know if when starting a print file it sends another M92 "just to make sure the active setting is correct before a print". Something it could in theory do, but without sniffing the serial port at the motion control board, it's all speculation".
***** Even if it did send one at the start of the print before any actual gcode print file was read and sent, the commands in the gcode print file would STILL then become the active setting because they are the most recent command sent, but only if an M92 is in the gcode itself, either put there by the user or some function in the slicer.
But, like said, Ideamaker creating the gcode is not as straightforward either. Example is, if you change the default steps per mm, then it magically includes the M92 command into the print file with the new parameter. *****It doesn't tell you or show you it is appending this and where in the gcode it goes.***** What we hope it doesn't do is get confused and add an M92 command with default 96 steps per mm let's say if you reverted back. Again, where this could mess up a user is say you do as recommended, you enter steps per mm in the LCD menu on the printer. That way loading and unloading uses the correct values -because failure here is painfully slow load and unload with a Bondtech that requires 415, but gets the stock 96, it takes 4X longer to load and unload filament!
But again, lets say for some reason you changed ideamaker, it was adding the M92 in every gcode print file (and you were unaware). Fine if the correct steps per mm is in that M92 in the print file. BAD if it's the wrong M92 steps per mm. The only way you would see it is by looking and reading the actual gcode file. If you use the normal upload- you never see or look at the actual gcode. You have to do an export to be able to inspect the gcode. Again, the thing that is a catch 22 is that the steps per mm setting is an automated "if changed from default" switch that happens without telling the user much of anything. That can lead to issues and confusion.