Posts made by pfn

Hi,

I'm currently developing an MFM alternative on rp2040 (https://github.com/pfn/rrf-rp2040-mfm-firmware) that supports mode-switching using an output pin from Duet, but I'm also using the output pin to check mode-switch status and read direction when using pulse-mode. When I create a GPIO pin for output, then switch it to input to read via sensors.gpIn[x] and then switch it back to GPIO output, if the Q-frequency setting for M950 is not altered, then M42 to the GPIO pin is subsequently ineffective until the Q parameter to M950 is updated. I am currently testing this behavior on duet2wifi and have seen this occurring on 3.4.6 as well as 3.5rc2

For example:

M950 P0 C"exp.heater3" Q1000
M42 P0 S255
G4 P10
M42 P0 S0
G4 P10
M950 P0 C"nil"
M950 J0 C"exp.heater3"
check sensors.gpIn[0].value
G4 P10
check sensors.gpIn[0].value
M950 J0 C"nil"
; any amount of `M950 P0 C"nil"` followed by `M950 P0 C"exp.heater3" Q1000` will not make any difference as long as Q1000 does not change 
M950 P0 C"exp.heater3" Q1000
M42 P0 S255 ; this does not take effect
G4 P10
M42 P0 S0 ; this does not take effect
G4 P10

M950 P0 C"exp.heater3" Q10000 ; switch from 1khz to 10khz
M42 P0 S255 ; this now works
G4 P10
M42 P0 S0 ; this now works
G4 P10

I'm overloading the pin that sends commands to my mfm to send data back to duet for 2 things: confirmation that mode-switches worked, and when operating in pulse-sensor mode also emit the direction of the pulse.

I don't know if this behavior is duet2wifi specific, the actual device I want to run this on is a duet3mini5. The duet2wifi happens to be an available board I can use for testing.

35.2g

It seems the 12864 menu issue is https://github.com/Duet3D/RepRapFirmware/issues/909 I guess we'll see this fixed in rc2? And then I can quote/escape the line to "M98 P""#0""" L"..."? I suppose I could also make the argument embedded in the M98 line...

Going by that, I would expect my macros menu file to be similarly non-functional as that is simply written as "M98 P#0" (https://github.com/pfn/voron2-rrf-config/blob/master/menu/macros)

X-Dron created this issue in Duet3D/RepRapFirmware

closed [Bug]: RepRapFirmware 3.5.0-rc.1 and Screens 12864 #909

I recently updated 2 of my printers to 3.5rc1 yesterday, one of them came from 3.4.5, the other from 3.5b4:

On both printers, my actions file in my menu system no longer function properly, none of the M98 lines execute the macro (https://github.com/pfn/voron2-rrf-config/blob/master/menu/actions). I think I also tried verifying the filelist macros and those didn't work for me, but others on discord were unable to repro.

Additionally, a problem similar to one I previously had in 3.5b2 has re-surfaced (https://forum.duet3d.com/topic/31812/3-5b2-macros-called-from-a-job-lose-parameters). When I use my job-prologue.g as start gcode in my print job, as soon as the heat-wait loop completes, execution jumps ahead to clean-nozzle.g which causes an abort due to either homing not yet being completed, or the print head temperature not being up-to-temp. The abort occurs immediately, but the job-prologue.g continues executing to completion, so the printer then proceeds to home and then set/wait for the nozzle to reach temperature.

Aforementioned files for reference:

• https://github.com/pfn/voron2-rrf-config/blob/master/sys/job-prologue.g
• https://github.com/pfn/voron2-rrf-config/blob/master/sys/k/clean-nozzle.g

I also encountered a problem with canceling a job, I don't recall the exact repro steps, but it is similar to what I previously described in https://forum.duet3d.com/topic/32937/3-5b4-dwc-stops-responding-after-canceling-a-job-on-12864 -- I think I canceled a job on DWC, and thereafter, the printer would not respond to any commands at the 12864 or vice versa.

@droftarts my guess is 99% a problem in dwc especially with the changes in multi-stream input behavior handling, but I have not had a chance to repro and see what devtools says

@chrishamm the setup is not operating in SBC mode. I am using an octopus 429. Next time I encounter this, I will check the js console to see if there is anything interesting of note.

With 3.5b4, both DWC & RRF, if I cancel a print job initiated from DWC using my attached 12864 display, DWC will stop responding. Refreshing DWC in the browser will get it to respond again.

I have not tested other scenarios as starting a job from 12864 is annoying. I discovered this mostly through initiating a job on DWC (re-start a canceled job) and then aborting it on 12864 as I am inspecting the print startup.

@dc42 ping!

Interestingly, if I do this on 2 different inputs, e.g. I run the testing macro on my 12864 display and force the homing to fail (depressing the endstop before the Y endstop actually hits the end), homing is blocked on DWC, i.e. DWC spins and blocks waiting for a result when I send G28 Y.

In order to clear this state, I have to G28 Y from the 12864 display.

I updated my homing scripts to be aware of an endstop/sensorless homing failure by adding logic to detect the position after the second pass homing move if it is out of range like so:

if !move.axes[0].homed
	; raise Z a bit
	G91
	G1 H2 Z5 F2400
	G90

; reset current position to 0
G92 Y0

G91
; Move quickly to Y axis endstop and stop there (first pass)
G1 Y315 F12000 H1

; Go back a few mm
G1 Y-5 F18000

; Move slowly to Y axis endstop once more (second pass)
G1 Y10 F360 H4

if move.axes[1].machinePosition > move.axes[1].max || move.axes[1].machinePosition + 2 < move.axes[1].max
  M84 Y
  abort "Homing Y failed"
  
G92 Y{move.axes[1].max}
G90

Now, if the homing move doesn't operate the endstop successfully, the homing script will abort. The interesting thing is, when the homing script is aborted, if I try to home again, I get this error: Error: G28: G28 may not be used within a homing file

After the error occurs once, I can then proceed to home again. It is as if the previous homing context that is currently running has not exited up a stack level.

However, I am not sure if this problem is a regression in b4 or always been present. I only just added this logic into my homing scripts due to a wiring problem that has manifested in my endstops over the last few days.

In case there is more going on due to multiple levels of stack, I am reproducing the above by running this macro over and over until my endstop triggers incorrectly, at which point the first subsequent G28 Y results in the error described:

G1 Y0 F18000
G28 Y

@OwenD This is only true, about not being able to use T, if there is a behavior change (undocumented) from 3.4 to 3.5

According to your posted quotation, T is only prohibited in custom 'G' code files (e.g. G123.g), and there is no prohibition on T in custom 'M' code files (i.e. completely valid in any of M123xyz.g). Additionally, it is not prohibited from general macros.

But it does sound plausible that the move to multi-stream processing might have a bug around honoring these rules.

@chrishamm I hope that's enough to fix my issue then. At the moment, this is 100% reproducible causing problems in my configuration--I have to run my start gcode separately as a macro before invoking my print job.

But for me, this happens regardless of a previous aborted print. A slightly different scenario, but maybe it's related regardless.

@dc42 \o/

There are situations where I want to detect stalls during macros and react accordingly. Is there any way to report if the last move stalled? In the object model perhaps?

@dc42 was there any change in b3 that would have helped here? I am currently avoiding b3 due to the news I've heard about extrusion issues with toolboards.

@dc42 thank you!

@dc42 reminder ping (I don't know how necessary it is with Tony creating github issues).

bump @T3P3Tony

@dc42 the macro is just a link to how I have everything setup, if I use M280 P2 S100 and subsequently run M280 P2 S0, the servo 100% reliably goes back to the 500us position.

If I use M280 P2 S100 and subsequently run M42 P2 S0 most of the time the servo stays in place, sometimes it will go to a position between S100 and 500us.

@dc42 I have this macro: https://github.com/pfn/voron2-rrf-config/blob/master/sys/mmu/lib/engage.g where mmu_servo_engage is set to 0 and it reliably sets the servo position to that of the 500us value.

@dc42 3.4.5