Will changes to the calibration pull force do anything at all? Or is it just set for calibrating?
1 Like
This is a great theory! I did confirm that the Z-stop setting wasn’t working correctly and it should be fixed now. I’ll post and updated version tomorrow.
1 Like
Tore Westre wrote:
Will changes to the calibration pull force do anything at all? Or is it just
set for calibrating?
I believe it is only used as the threshold of how hard to pull on the belts when
calibrating before considering the belt 'tight.
But if the calibration ends up with wrong anchor locations (i.e. further apart
then they actually are), then when you go to use the machine it will have the
belts loose.
David Lang
1 Like
Firmware version 1.09 is out!
1.09 adds a pause button and also a display which shows real time current draw to each motor which I’ve been enjoying watching.
As always let me know if you find any ways that it could be improved!
1 Like
Oh that’s very interesting, so I could, for example, run a simple pattern XY pattern with the router up and not cutting and then repeat with it down and cutting and keep an eye on the currents? 
It sounds like interesting data, no idea if it’s useful or not though 
2 Likes
Yes, you absolutely can!
There are all sorts of interesting insights to be had
1 Like
Updated the machine to the latest here maybe by the grace of god it would work but as expected it does not work, yet again.
I loaded V1.09.
It does not like a zero value in the Z positions, (I.e. TRZ etc) Error can’t find XY location, so changed that to 10.
Pausing and then restarting worked. It would be nice to be able to cancel a job part way through.
When I paused a job, machine just ignored whatever I did from then on, until I did a power reset. (Except for Run).
After restarting and doing the Retract Extend dance it seemed to have lost position and headed for the hills. Killed power and am giving it rest for a while.
The position was not related to actual position as worked out by the Retract Extend. I had set the home position to bottom left, moved off it by x=126, y=302 & z=-20. On resuming it had set the position to x= -74.283 & Y= -2.895. When I tried to re-run the test print again it started heading off diagonally Up and Right. Previously (earlier versions) when I reloaded after a failed attempt and started it again, Z required resetting but it would start the action relative to the previously defined (XY) Home position. This wasn’t a failure I interrupted the run.
Really like the current readings, could you make them bar graphs and put them on the main screen? Maybe crunch the X,Y& Z values closer together and put them next to that. A work around for this is I opened another session on my phone and put it in debug mode, so I could watch the current values and the job progress at the same time.
I really like the feel of this version, thanks for the continual effort you put into this machine.
1 Like
Installed and calibrated version 1.09 without issues.
I noticed the config has settings for spoilboard and workpiece in two places.
Is this for having a standard setting and an override of the standard?
Great feedback! I’ll look into that and see what is going on there. I did add settings for spoil board thickness and material thickness which interact with those z-values so maybe there is a divide by zero or something happening there. Great catch!
I agree! I think that pressing stop in the pause state should end the job but restore control. The way FluidNC handles everything internally is a bit chaotic so that might take me a little bit to get added because I need to sit down and really understand what exactly needs to happen to end a job without leaving something messed up.
This is super interesting. No idea what is going on there, but I will try to replicate it.
I confirmed that this was a bug and it will be fixed in the next release. Thank you for catching that! 
No, what are the two places? I thought this was just going to be in the settings
tab, not yet exposed elsewhere
David Lang
2 Likes
Hi Juan, I’ve been researching the net on faulty wifi connection to cnc’s. Apparently this is a frequent issue with other machines as well as the Maslow4 (Onefinity, Longmill, etc). I am not a network guy, but it seems like it has a lot to do with how the individual home networks are configured. Our machines may be fine, but our individual network setups might be the source of the interference. In the days of early networking, they had something called p2p (point to point) networking which connected two computers directly. It was often done with cat5 wire between the computers. Right now I am researching how to make a p2p connection wirelessly to the Maslow4. I don’t know if that will help with our connectivity problem, but I will keep you posted.
1 Like
I meant the settings under the FluidNC tab when I said “config”. There are 2 places I can set both values.
I don’t have access to the GUI now, but I think it was:
\Maslowkinematics\spoilboardthickness
\Maslowkinematics\workpiecethickness
Then again further down:
\kinematics\Maslowkinematics\spoilboardthickness
\kinematics\Maslowkinematics\workpiecethickness
I left them all empty and changed Z-offset as usual, since I didn’t have time to experiment.
I just noticed when looking through the fields after updating.
When testing the probe-function in 1.09, it seems to act as it did in 1.08. It goes down until contact, but it does not raise to the set value afterwards. The Z-Home does autosave, but never at 0. Always -0.12 or in the vicinity.
It also threw an error in the command window under the FluidNC GUI-tab, but I didn’t manage to save as the text seems to be buggy. It puts out almost everything on one line rather than using line breaks. Could have been Error 2 or 9.
1 Like
I’m seeing this too! Thank you for catching that!
These are not actually interstitial releases, these are the full point releases.
You are doing a lot of development work and merging fixes, can you make it so that when you merge a feature you do a build and make that build available? those would be the true interstitial releases and give others a chance to test them before your weekly release (or test after a significant bug is fixes, for exampke, this week you found that the forward and reverse kinematics weren’t consistent)
1 Like
Some suggestions:
The test (as per the test button) routines be incorporated into the Configuration routine. This would let us see if there is a problem with the set up by looking at the serial log file generated. Only one file would need to be requested.
Add a test to compare the current required to move TR & TL against BR & BL which could be an indication if we are horizontal (similar values) or vertical (differing). This test would be part of the Test button routines. Also if it requires a larger current for a particular arm it would indicate a potential problem with that arm.
Under test routines report whether vertical or horizontal mode from yaml file.
Anyone having problems with configuration should be encouraged to provide a full copy of the serial log file initially to help diagnose the problem.
1 Like
I love this. It’s a great idea. We could just run it at boot up. I am adding that right now.
I was thinking about this too, but I’m worried about it failing if someone has extra sticky arms. They can vary quite a bit.
My current plan is to try extending the tl and tr belts for 500ms or something and then measure with the encoders how much belt actually extended. In horizontal mode it should be a lot less than in vertical mode. TBD if it’s reliable.
Extra sticky arms indicate a potential problem which displaying a warning might mitigate before it becomes an issue. I wasn’t suggesting stopping the machine, just an indication of a potential problem or a place to start looking when odd things happen.
1 Like
Hey Steve,
I think it’s hardware wise. I’m not using the home WiFi rather the Maslow self made network. There were a few suggestions of privatizing the network and other settings but they didn’t work.