Interstitial Firmware Releases

Software Maslow Firmware
764

I agree, the anchors are not going to be moving on that frame.

I am reluctant to tell people to run ‘find anchors’ again because if you haven’t solved other problems, it doesn’t help. But in this case, it seems like we’ve looked at everything else and not found anything obvious.

I would suggest filiming the find anchors run so we can look through it and see if there is anything obviously wrong (and if it works, it gives us a video to point people at for what it should look like when it works :slight_smile: )

765

to check the magnets are seated properly do a retract, extend, retract and the belts should retract the 2nd time with an offset close to zero.

766

David,

Tomorrow when I get back to school I will film it. For now, I tried to find the anchors again and it lost connection in the middle.

Maslow-serial 2-18 @ 1254PM.log (4.0 KB)

I clicked to reconnect. It did, but nothing happened after that.

Maslow-serial 2-18 @ 1254PM.log (4.0 KB)

Fluid NC 2-18 @ 319 PM.txt (11.5 KB)

When I get back in the morning I will try the extend and retract test Ian described. I will also film calibration.

Any other advice or insight would be appreciated.

Thank you,

767

nothing in those three log files that would indicate a reason to disconnect. what version firmware is this? The current pending branch has some additional logging that I don’t see here.

768

Good morning,

I am using the firmware version that was uploaded 2 days ago by Bar in message 752 of this thread.
I tried calibration this morning, it failed again.

Maslow-serial 2-19 @ 958AM.log (63.0 KB)

FluidNC 2-19 @ 958AM.txt (5.8 KB)

Here is the video.

I am reinstalling the latest firmware again and the latest index files, and then attempting calibration again.

Thank you for any help you can provide.

Update- 10:20 Am

I had it do another calibration. It failed too, only getting a fitness of .42 ish, and ending in extended state. I then clicked release tension, and then apply tension. And it said ready to cut. I uploaded a gcode to it, it then disconnected when I tried to jog over to where I wanted to start the job.

Maslow-serial just dropped 2-19 @ 1019.log (3.9 KB)

It immediately reconnected when i clicked to reconnect. It then started jogging when I clicked the button. Currently adding a bit to try and cut something today.
Thank you,

So that didn’t work. I was running this gcode:

Coaster_AJ_JG1.nc (212.8 KB)

The Maslow started moving, went up to cut the first feature, which should have been to a depth of .125 inch, and plunged to more than an inch deep. It did not slip from the bracket, the apparatus dove to the Z stop. Z home had been set so that the tip was just above the bottom plane of the sled.

FluidNC 2-19@ 1115AM.txt (28.7 KB)

Maslow-serial 2-19@1115AM.log (8.4 KB)

After clicking pause, and then stop, I was unable to raise the Maslow in the z direction. So I had to cycle the power to get control of it to even move the maslow so I could see what it did.

Please advise.

Update: 12:50 PM.
I don’t want to jinx it right now, but I re-uploaded the PRIOR 1.17 beta, (I called it 1.17-D above) and it’s running. Z axis is holding at the correct depth. I was careful to be sure to define Z stop and then define home this time. All that jazz.
I have no idea. :rofl: :face_with_peeking_eye:

Any insight would be appreciated. Thank you,

769

There’s something funky happening with the Z value in this release. Haven’t quite worked out what yet but it’s not ready for release.

1 Like
770

If we lose WiFi connection, the M4 stops (good). On resumption it may not restart job, sometimes does sometimes not. Display may/may not show GCode file.
The home setting is lost with x and y values of NaN, although reloading file and restarting, it starts in the correct place.
Sometimes requires a power reset to get back to rational operation.

[WIP] Fix loss of XY home position due to WiFi failure#795

1 Like
771

Good afternoon everyone,

Well, at least the Z problem is known with that version. I was worried that something else had gone sideways.

Also it seems like mine primarily loses connection when you change what it is supposed to be doing. So like clicking find anchors triggers it occasionally, jogging across the workspace does the same.

In other news, Success!

image
image445×538 76.6 KB

This is a student job that is a coaster to learn the limitations of the Maslow. It cut, so that’s good.
If anyone has any tips on how to get it to not be such stringy cuts I would appreciate it. The 4.1 on top was cut on the same settings as student’s coaster.

The only issue I had with this job was the fact that when I went to jog the Maslow off to the side so I could see this, it ran away. I set it to 250 mm jog, and after about 500 I had to cut the power because hitting pause and stop didn’t change anything.

FLuidNC 2-19 @ 249PM.txt (7.3 KB)

Maslow-serial 2-19 @ 248PM.log (7.1 KB)

So I am happy to test another firmware, but I also need to get projects cutting.
Thank you!

772

Not sure where to put this. I’m using the same firmware 1.17 beta that I used in my prior entry. This morning has been troubling.
The first gocode I loaded to run caused the Maslow to run away up in the z direction. I had to unplug it to stop it from moving. It did this twice.

Coaster_AM_JG.nc (222.0 KB)

Maslow-serial z runaway 2-20 @ 740AM.log (6.4 KB)

I then reset it, retracted, extended, re-zeroed the Z and reset the XY home position, then tried a different gcode Now I keep getting the error of a motor exceeding 4000. Once it caused my new gcode to fail. It is currently running now. I see that it started this yesterday at the end. I restarted in a new location and now the warning is in literally every line.

Coaster_KK_JG1.nc (327.4 KB)

Maslow-serial cut fail 2-20 @1019AM.log (12.1 KB)

FluidNC 2-20 @ 1020 AM.txt (30.2 KB)

During this cut I noticed the upper right belt was loose.

Does this mean that I now need to disassemble, sand, and reassemble the rest of the paddles. Do you recommend dry graphite as a lubricant? Or do you have something else that you recommend? Or is there something else that is causing this problem? While cutting I see that the tension in the lower right belt is a little lower than the other 3, and they seem like they are about equally tight.
So where do I go from here?

Update 3PM.

Ian mentioned I should run a test for the displacement when I extend and retract the belts 2 days ago.

Maslow-serial Belt Positions 2-20 @ 224 pm.log (9.4 KB)

FluidNC Belt positions marked 2-20 @ 224PM.txt (2.7 KB)

The variations in belt length are near zero in my mind. But are they close enough?

While running this test, I noticed the threshold had to be increased to retract the lower right and the upper right belts. So I guess I will be pulling apart the paddles this weekend.

Thank you all,

773

Hmmm I don’t see anything crazy in the log there. It was the z-axis which moved up a lot? Was it after pressing a button?

They look good to me, but from looking at that log it looks like it’s taking multiple tries to get them to retract, is that right?

774

Bar,

When the Maslow ran away in the z axis, I had clicked go to start the job. It moved up and to the right from home to get to the correct location, but then it moved vertically up until it ran off the spindles.

For the retraction, yes, I had to click retract a couple of times, each time increasing the force to get them to retract. My final run at the retract/ extension test I had it at the elevated force to have them all go at the same time.

My thought is that if the lower right is trying to draw it down that way, but the lower and upper left are not extending properly, then that could cause it to require the extra force to draw it to the right. So my plan this weekend is to disassemble it, sand it down, and hit it with some dry graphite. That is unless you have a better lubricant to suggest.

Thank you,

James

775

Hi James, I used a mix of graphite and grease on mine. It was pointed out that that might cause problems with interaction with the plastic. I think a silicon grease is the recommended option.

776

Works great

https://a.co/d/0hpElsu2

777

@bar I have been working on disconnecting the WiFi to the host computer and observing what happens to the Maslow while it is running a Gcode file.
I have noted two different effects

  1. For a short duration interruption, the Maslow can continue operating on the last instruction it received, i.e. continues cutting in a straight line until powered off. This requires a Retract etc.
  2. For a longer duration break, The Maslow completes the GCode on it’s own, on reconnection of the browser, it may/may not allow buttons to resume control.

#805 saves the current location then triggers the pause button response, for short duration WiFi interruptions. On reconnecting the browser the job information is lost but the Maslow can resume without needing to Retract, Extend and Apply Tension.
For longer duration interruptions the job continues (I don’t understand why).

Trigger feed hold on WiFi disconnection and log position on pause#805

1 Like
778

I think that this should be the desired behavior. If it loses the wifi connection I think that it should keep cutting to the end of the file. It would be a bummer to have a big job interrupted because of a wifi outage.

Obviously we want to it to allow the buttons to resume control on reconnect, but I don’t think we want to stop the cut

779

The problem is with a really short wifi break, the Maslow continues to cut in whatever direction it was last going. I think this is what was happening to James, when the machine took off across the workpiece and when it rolled the Z axis up off the top.

1 Like
780

Yeah that is 100% not the behavior that we want.

Are you able to replicate that behavior?

781

Yes, by disconnecting WiFi from the computer I have the controlling browser on and immediately reconnecting,about 50% of the time the Maslow just keeps going on whatever trajectory it was last on. It then requires a power off to stop it, followed by a retract extend etc

1 Like
782

Ian Abbott wrote:

The problem is with a really short wifi break, the Maslow continues to cut in
whatever direction it was last going. I think this is what was happening to
James, when the machine took off across the workpiece and when it rolled the Z
axis up off the top.

I’d bet that this isn’t proper movement, but is instead the system locking
up/crashing and leaving the PWM settings for the motors running, and continuing
to move the motors.

We’ve had occasional reports of the maslow sitting and just spooling out the
belts until unplugged

I created a patch for a watchdog to stop the machine if it becomes unreponsive a
few versions back (prior to the repo consolidation)

if we can duplicate the runaway and can do it with a USB connected, we can see
if we are having a crash or a wifi disconnect

David Lang

1 Like
783

Ian Abbott wrote:

Yes, by disconnecting WiFi from the computer I have the controlling browser on
and immediately reconnecting,about 50% of the time the Maslow just keeps going
on whatever trajectory it was last on. It then requires a power off to stop
it, followed by a retract extend etc

can you capture the USB logs while you trigger the problem?

David Lang