Best way to detect printer state

svenyonson

I am in the process of upgrading my custom printer with a Duet Wifi (from Ramps/Marlin). No worries/issues about the conversion, I've already converted my Ender 3.

But my old Marlin machine was easy to update the firmware with Arduino IDE. I had added hooks to set GPIO pins to generate PWM levels for RGB lighting for various states: Idle, Initial Heat, Printing, and finished. It looks to be far more difficult to build the Duet firmware - (maybe not?) - but I was wondering if there was another way to get this information (eg. into a microcontroller) without modifying the firmware? Just fishing here, I'm prepared to dig in and build firmware, but not before I ask if there is are pins to sample, scripts to write, etc.

frank26080115

I have used extra fan pins to control a bi-colour LED.

I have a single script file for starting a print and a single script file for ending a print, I could easily have different colours for those four statuses you mentioned by writing the LED commands into the scripts

this is not really reading the status, it's more about how you are always in control of what status you are in, because you wrote the gcode files that run before/after every print

of course this won't turn on the LED red just because you've manually enabled the bed heater without actually starting a print... but for 99% of use cases, it works

edit: another idea is to just intercept the communication between PanelDue and the Duet with a microcontroller, or rather, make that microcontroller poll the status of Duet via UART commands. This will get you much more information, but requires a lot more hardware.

svenyonson

Thanks Frank - yeah if it was just start/end events then I could just use gcode scripts. I came across another post about wiring up a microprocessor to the PanelDue port - I think that's what I'll try to explore. I have lots of microcontrollers lying around from late night impulse purchases, so I'll likely give that a go. I just wanted to be sure there wasn't an easy way to register scripts to "listen" for printer events. Probably overkill for most but that would really be powerful. No mods to the firmware, just write some gcode scripts (for my Marlin build, I implemented some new codes - "U" (user) codes that would control GPIO pins for my LEDs. So some of the LED changes happened with the start/stop events that already exist, and the initial heating was triggered from within the firmware.)

dc42

The PanelDue port uses 3.3V signal levels. So don't connect 5V electronics to it without using level shifters.

svenyonson

Well, looks like the PanelDue interface won't help me. I'm looking for a printer state that is not enumerated in PrinterStatus - where the printer is waiting for the bed and extruder(s) to heat to target temperature before the initial home all.

enum class PrinterStatus
{
	connecting = 0,
	idle = 1,
	printing = 2,
	stopped = 3,
	configuring = 4,
	paused = 5,
	busy = 6,
	pausing = 7,
	resuming = 8,
	flashing = 9,
	toolChange = 10,
	simulating = 11,
	off = 12
};

dc42

The reason there isn't such a state is that RepRapFirmware can handle multiple commands from different input channels concurrently. So while one channel (e.g. SD card is waiting for something to heat up, another channel can be commanding movements.

It's possible to get the status you want by sending the M408 S0 command. Here is a sample response:

{"status":"I","heaters":[34.2,150.4],"active":[0.0,200.0],"standby":[0.0,200.0],"hstat":[0,2],"pos":[0.000,0.000,465.073],"machine":[0.000,0.000,465.073],"sfactor":100.00,"efactor":[100.00],"babystep":0.000,"tool":0,"probe":"0","fanPercent":[0.0,0.0,100.0,100.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0],"fanRPM":0,"homed":[1,1,1],"msgBox.mode":-1}

"heaters" is the array of current heater temperatures, "active" is the array of set points, and "hstat" is the array of states, where 0 = inactive, 1 = standby, 2 = active. So if the state of a heater is 2 but the current temperature of the heater is well below its setpoint, it's reasonable to assume that it is heating up. In this example, heater 1 is heating up.

The M408 S2 and M408 S3 responses provide even more information, but are harder to parse because they use nested JSON variables.

svenyonson

Thanks, I'll look into that. It seems I could infer the initial heating phase by detecting the transition from Idle to Printing (heating begins) and then wait for all axis' to be homed (heating complete). It's just for lighting, not critical path.