ZenXY FluidNC RMRRF 2024

I think the basic issue is that when it is running in a gcode script, or a startup script, it is in “Run” mode. When it reads $HX in “Run” mode, it has this error: [MSG:ERR: 8 (Command requires idle state) in /sd/home.g at line 3].

The $HY is fine, because it reads that and accepts it before it goes into “Run” mode.

In some circumstances, the ERR: 8 is still happening, but I don’t think it is reporting it.

When I run the commands from the terminal, after each command, it returns to “Idle” mode.

So 1) The devs want $H to not be run in Run mode. 2) It is getting through if it is the first thing in the gcode.

I could probably find and kill whatever check only lets $H happen in idle mode and compile my own firmware. I bet if the devs had their way, they wouldn’t want $HY to work that way either.

What is a solution that would not mess up other machines?

Can’t be a negative pulloff, because we still need a pulloff to trigger twice. mm-pos seems correct, nothing we can do there except force a move to The zero position between the homing cycle (fluidnc guys won’t like that). Can’t allow “$” commands while in run mode or all sorts of funky things could happen (I assume this is how grbl used to work).

The only thing I see is me redesigning adjustable flags (or endstops)…that is a bummer.

Currently for your situation, trim to fit flags is pretty easy. If you mess up you can just use some tape or glue to add some length.

I’m not sure why there is that limitation. I can put G28 anywhere in any Marlin firmware gcode and it doesn’t explode.

I don’t really want to do that. I would rather edit the firmware. But I might get to that.

I think the solution I settled on last year was to just unplug the machine, move the head to 0,0, and then plug it in there. That would also fix this.

boot to a gcode file and have those lines in there as your starting gcode? Or is that what you initially tried and I am just realizing that???

can you insert a dwell command that is long enough to make sure it is done with the first set to run the second half of the lines? Maybe it just can’t be in motion?

I started with home.g that had $HY, G1, $HX, and it would throw the error (because it is in run mode when it gets to HX).

G4 P20 ;delay 20 seconds

:bangbang:

$HY&G1Y3F600&G4P2&$HX&G1X10Y10F600

This works! And in one line.

2 Likes
105 macros:
106   startup_line0: $HY&G1Y3F600&G4P2&$HX&G1X10Y10F600
107   startup_line1: G4P2&$SD/Run=RMRRF_V1_Spins.gcode

I added a G4 to the second line too. That is working too.

The WLED is also defaulting to the rainbow preset. So I should be able to just turn them both on and they will start impressing.

Shippit

1 Like

Dude!!!

OMG, I had no idea how much that was bugging me. I feel amazing, like the sun is shining a little brighter.
Something on a dusty old to-do list solved.

Thanks for fighting through it!

2 Likes

And of course a new fluinc just dropped

2 Likes
  • Successful homing cycles are reported. Primarily for pendant and display status
  • Lots of little fixes to support pendant features, like macros.

Hmmm.

1 Like

Slap a pendant on it… :sweat_smile:

A pendant would be pretty fun. I don’t have the M5 dial, and realistically, I haven’t got the time before RMRRF. That would be a better long term goal though.

1 Like

For this gap on the bottom edge: I am thinking just clear packing tape. Blue masking tape would work too, but it might be distracting. That gray piping didn’t work well last time.

1 Like

The ball should roll over it pretty well, might see a ghost edge, I kinda doubt it though. Worst case cover the whole thing with a tape layer so there are no edges to roll over.

A Pi with a small touchscreen for some basic features? Home, and select from some known filenames?