Hey @anna, just wanted to make a clarification regarding what you mentioned above. So since the yaml file stored locally on my machine has the calibration info which is specific to my machine, what happens when we’re to download and replace the yaml file during the periodic updates? (Btw, all the how-to-videos are much appreciated!)
1 Like
So you don’t actually have to update the Yaml every time you update the firmware, and Bar should specify if it’s needed in the little description of the update that he writes on Github. But before you do update the Yaml, if needed, first go to the config settings under fluid NC.
Then save these values shown below, They are the locations of your anchors. So when you upload a Yaml update you can add your anchor locations back in
Maybe I should make a Yaml update video too 
4 Likes
Okay, that totally makes sense now! That’s easy enough. (Now I’m thinking that this was the culprit behind an earlier issue I had where my belts were no longer reaching the anchor points. Someone then looked at my yaml file and noticed that the frame size listed was different than the actual frame size I had measured. But we weren’t sure what had caused that. Meanwhile I had updated (straight replaced) the yaml file at one point before and wasn’t aware about editing it to retain these coordinates. So that probably explains it.) Thanks!
1 Like
Oh no! Sorry about that, We are trying to eliminate the need to update the Yaml at all, ever. so hopefully this little process won’t be necessary at all soon.
2 Likes
No worries! This is all a good learning process. You guys have the continuous improvement approach in place so we can’t ask for better than that.
1 Like
Maybe I should make a Yaml update video too
Something like that might be best as a reference document that doesn’t need watched and scrubbed through if someone needs to take it at their own pace, especially since it’s such a short process.
Wouldn’t be terrible to pair that with a short clip of someone going through the process and narrating it.
2 Likes
Hi. Yes thank, you your suggestions were good ideas.
I had tried them, as well as switching post processor and several other things such as trying gcode clean. The crash remained until I recalibrated. Then no crash. I think the gcode is a bit exotic but not the culprit here.
Michael
1 Like
Right, the crash is sensitive to calibration. I dont see it after recalibrating, so im not suprised that things changed your side. The only way to get to the bottom of this is with my (bad) calibration file and one of the crashing gcode files. The circled green arc @bar indicated is where it goes belly up with my calibration.
Cheers for digging into this aggressively
1 Like
Yes, that’s true. If this particular step is perhaps just added to the User Guide document (maybe under or linked to the firmware update section) then that might be helpful for anyone else who be doing any updates for the first time.
(Btw, sorry Michael for having briefly hijacked your post. Lol. New to forums here. Next time I should probably post as a separate issue.)
I’ve been trying to replicate this issue, but I haven’t had any luck making it happen.
I’m using this config file:
And I’ve run the gcode from these two files:
Both of which seem to work normally for me.
I am using the machine a little bit differently since I don’t have a frame that is the correct size for the config file I am running the files with the motors disabled so the machine isn’t actually moving, but it is doing all the computations for the belt lengths based on the config file and the gcode path in the files.
Thanks for the feedback @bar. Let me do two things
1: I’ll go back to my workshop and double triple check the failure
2: If it is possible, could you tell me how to disable the motors and I can try as you have tried for a second sanity check
Ideally I would go to the workshop after getting confirmation on how to try 2 my side or a hard no on doing that.
So I’ll hover around here for 5 hours in the hopes of hearing back.
Cheers!
Michael
I made a special firmware version for testing this. Basically the way that it works is that it skips all the checks and error messages that would normally prevent you from running a file with the belts fully retracted.
To run a file without the machine moving just retract all and then press play. The z-axis will still move and the cooling fan will run, just the XY motors won’t move, but it will still be doing the calculations.
firmware.bin (1.8 MB)
@bar that is absolutely awesome!
I will report back to you on this as soon as I can. A bit slammed with work for the next day or two but boy oh boy am I keen to test it.
thanks again!
1 Like
OK so the good news (?) is that I can no longer reproduce the crash. That is great except I don’t know why. It was 100% reproducible previously.
The check I did was to just run the previously crashing gcode using the previously crashing yaml and for good measure with the reportedly non-crashing yaml. I did this with vanilla 0.78.1 firmware, not the debug firmware, and I did not see a crash.
@bar I don’t really like magic fixes like this but whatever. Lets drop this unless it somehow manifests again. Final thought, @anna did seem to see a crash in a different location so there is for sure something weird going on but I don’t have the means to review what she saw. If she still does you could maybe double check that setup before moving on.
Thanks for looking into it!
1 Like
Thanks for reporting it! I’m sure that something that we learned along the process will help us fix an issue down the road. There are 100% still bugs in there that we need to get, and I think we gained some valuable tools in searching for this one