Maslow started moving in 1 direction during cut

Make sure that your bit isn’t slipping out of the shaft. It happens (to me) every once and a while on my gantry CNC.

1 Like

So no verdict yet on whether command/control was more stable over USB. I will note that in a shared environment, it is possible for someone else to connect to the Maslow AP and send “your” Maslow commands. For example, if you have another one running and the cord-management isn’t quite dialed in and it unplugs itself at the very edge of the board, so the laptop controlling it loses its connection, and connects to the next available network, which might be the one you are connected to via USB.

So it looks like OpenBuilds Control is viable. There might be some tweaks to be done by someone more familiar with ‘normal’ CNC operation / GRBL, etc.

Will see if the Z-axis problem persists and may have more data tomorrow.

For those who asked about cable management, etc, here are some photos of the setup. Not sure if this is ideal for warding off EMF gremlins, or attracting and amplifying them!

1 Like

Would you mind sharing your openbuilds control macros? Its easy. Just right click and select export. Thanks!

1 Like

Maybe try this on DC 24v supply cord:

I wondered about that, but it doesn’t account for the fact that the entire router assembly is twisted - one side is higher than the other, as if one side is unplugged. But we are going to try mounting it a bit ‘lower’ so that the assembly sits higher when zeroed. Mostly because we have that chunk of air hose between the sled and the router for dust collection and not clear if it can be compressed to machine zero! Having the bit higher will reduce any ‘resistance’ it might be mounting (though I think insignificant, but we’re just tilting at windmills here so… :slight_smile:

1 Like

I think that is a reasonable culprit, the steppers will lose steps instead of throwing an error if they aren’t free to rotate so if they go low enough to compress the hose it would be reasonable that one side might end up not even with the other.

Re the original issue of the machine moving in one direction, this week’s update Release v0.76 · BarbourSmith/FluidNC · GitHub should fix the “moving in one direction” part because it will stop the machine, but it won’t fix the core issue of the firmware crashing if it loses the wifi connection while running a file. I’ve tracked that down to an invalid pointer somewhere in the serial system but I’m still working on a fix.

3 Likes

Does the hardware and firmware support lost step detection? I thought that was pretty common on stepper controller chips these days.

1 Like

WFD wrote:

Does the hardware and firmware support lost step detection? I thought that was pretty common on stepper controller chips these days.

I believe the controlers we are using can do the detection, but that is less
than perfectly reliable when there is a lot of interference around, so I don’t
know if it will be usable or not.

David Lang

1 Like

Easier to type them and I spent too much time looking through the limited options for icons, but here is what I came up with:

Sorry no lavender so went with light blue.

control-macro-backup-Release Tension.json (193 Bytes)
control-macro-backup-Apply Tension.json (193 Bytes)
control-macro-backup-Extend All.json (194 Bytes)
control-macro-backup-Retract All.json (198 Bytes)

There might be some better options for apply/release, or switching them. Not quite the same symbol set as emojis, but

:necktie: / :wine_glass:

6 Likes

Those look fantastic!

Thanks! :+1:

Hey Derek,

Just following up to see if you are still using openbuilds and if its behaving well. I’m thinking about repurposing an old computer for use in my garage this weekend, and if I do that I’d want to go to openbuilds control or other grbl connections either via usb (preferred) or telnet.

2 Likes

I have not spent any more time with it – but I definitely think it would be worth getting some feedback from someone who has more CNC + Maslow experience. I was looking at it as a possible way around the FluidNC crashing issue, but at some point realized that the “call was coming from inside the house” most likely, so decided not to add that complication to the set up yet. (Maybe if you re-built the firmware with the webUI removed after getting calibration values, you could try to evaluate that aspect - truly USB only control, vs having the web server running without any active connections).

I had one issue where I think it got confused about its idea of ‘home’ vs Maslow’s so it drove it off the edge, but after a re-set and re-home it seemed to work, at least minimal correct path. The macros did what they needed to do, and the built-in alarm detect / button seemed to work too. I didn’t do multiple runs so don’t know about that (i.e. crew reports that Z appears to be drifting if they try to cut again without doing the full retract/extend dance (and possibly re-home), but I haven’t verified that personally. And that’s with MaslowUI anyway).

I think that’s probably worth a separate topic, or I need to take a minute and look through the code - but for example, in OpenBuilds or Maslow WebUI:
→ Calibrate
→ Set Z-Zero
→ Install Bit, set Z -Home
→ Load Gcode, Set Home (Maslow UI)
→ Cut
→ Release Tension
→ Move Maslow, unload and re-load material
→ Apply Tension
→ Cut

One would think that the Z-axis would be the same… but after hearing that the crew following this process felt like the z was drifting - not sure if becoming shallower, or deeper - but I did see some boards with noticeably shallower cuts.

=> Made me realize that I don’t know enough about OpenBuilds vs Maslow UI and Gcode conventions with respect to “home” settings due to having not put in the time outside my narrow window of engagement.

  • I assume MaslowUI only sets X and Y when you define Home, and only Z when you define Z.
  • Not sure if I set z ‘home’ on open builds with similar procedure (i.e. up/down until bit just below surface of sled, set z home to ‘zero’ in openbuilds UI. Is there something that should be communicated to Maslow/FluidNC internals that happens through GRBL since it’s not happening MaslowUI, etc.
  • Similar for X and Y, and the whole machine home vs. whatever the other option is - and how much of that ‘state’ is maintained by the ‘controller’ - either OpenBuilds or FluidNC vs the “UI”…
  • what happens after a ‘failed’ cut? How well is the current z position vs. defined home vs. last z position retained after power loss due to restarting because of crashing problem, etc.
  • I saw in another post that @bar said something like z home needed to be reset at every cut, but I assumed that he was probably expecting a different bit/cut, not repeated cuts with same setup.
    => So I didn’t fully explore that homing behavior to get an idea of exactly what it does, and what a reasonable person might expect it to do, etc.

I think the hourglass crew has paused production hoping for a firmware update that will get them operating with less interruption. I’m out this weekend at opensauce, where I’ll be checking out @AzaB2C ladder frame set up.

It might be a few weeks before I get a chance to try it out again - out backpacking for a few weeks, etc.

2 Likes

Derek Graham wrote:

One would think that the Z-axis would be the same… but after hearing that the crew following this process felt like the z was drifting - not sure if becoming shallower, or deeper - but I did see some boards with noticeably shallower cuts.

mark your bit and see if it’s slowly working it’s way into the router or if the
Z on the maslow is drifting.

I think that the bit drifting is more likely the problem.

David Lang

I saw your post. Looks fun! Thanks for taking the time to reply. I’m hoping to get some time this afternoon to play around with openbuilds control. I have an old 2013 macbook that I can use to try it.I’ll start a new topic in “software” once I have some observations.

That’s a good point. We have been experimenting with having more of the bit shank exposed so that the home is higher on the z-axis so that there wasn’t any conflict with the chunk of air hose we have between the router and the base plate when plunging.

When I updated firmware the other day and swapped in Maslow3 I noticed some of the bits being mounted even further out than I would have. That coupled with the potential slipping of the clamps during bit tightening is something I’ll have to watch out for. I’ve had to release the clamps and re-align the router to make the spindle lock workable several times. Once I noticed the router was mounted a bit higher in the clamps, not sure if due to operational drift or it happened during assembly. Another time the router slipped in the clamps, I think different Maslow unit. And I’ve noticed changing bits that the button presser gets difficult to remove, didn’t think about it being potentially due to router rotation… and trying to get the collet tight enough.