Sorry messing with the configs still. Should I home X and Y together instead of separate like they are now. We have buttons to do them one at a time, but if you hit the home all button, Z homes first, and on the LowRider especially, homing X and Y together can save some time.
3 Likes
I like that better than how you have it set up now. That was something I always changed. I have X home then Y last. I was used to that with marlin lol. And I am bad about stacking stuff at the front of my table. First few times I homed with the jackpot the dust shoe wiped everything off the table 
Homing X and Y at the same time sounds great to me.
1 Like
I like this plan too! I usually work on my table at the front and end up pushing the gantry back. When I go to cut it takes awhile to home everything.
2 Likes
Yes sounds good to me too.
The only macros i use are for my xyz probe named by bits size. So i do read the sizes 1.5mm - 1/8" - 6mm- vbits and the 25mm spoilboard bit. After that pretty much everything is handled by gcode fror each job
1 Like
I just use the tablet screen. Only use the main screen for homing the machine and setting z height ( soon will get the fancy rapidchange atc and take care of that. I dont use the spindle override, i have pretty much everything set
So I am not sure if something is wrong or not with the new webui v2
$HTTP/BlockDuringMotion=on as shipped, I get the warning screen as expected. You can cancel, pause, or reload webui…reload webui does not work.
When you pause, the reload webui option goes away. so you can only resume or cancel.
This is incorrect in my eyes. When I hit pause, at that point we should be able to load the webui, I assume.
That’s correct. This is something that got accidentally introduced while they were trying to fix the crashing.
I’m going to PR a fix for it soon. So hopefully it will be fixed for 3.9.2
1 Like
I just loaded this when i transplanted! Only homed so far. I need to cut my mdf from the old table, then try cutting with it!
Man that webpage is soooo useful!
Wild thought, can we transfer system to sd and sd back, for upgrades?
There is a $LocalFS/Backup command which backs up everything in Flash to SD. There is also a $LocalFS/Restore command but it looks like that requires you to specify each file.
http://wiki.fluidnc.com/en/features/commands_and_settings#localfsbackup
I created some PowerShell scripts that backup all the flash files to a date/time specific directory and can then specify which directory to upload back to flash.
What I should create is something to restore my wifi settings. I know it appears to be recommended to wipe flash when upgrading, but I almost never do and haven’t had issues. If I do have issues, that’s the first thing I try.
3 Likes
Curiosity got the better of me. It seemed that if Backup did all the files, why wouldn’t Restore do the same? On the FluidNC wiki, the documentation mentions a file for restore. But, I looked at the FluidNC code and it does the whole directory. So, I tried it. Yea, $LocalFS/Backup backs up all files on Flash to a /localfs directory on SD. And $LocalFS/Restore takes all those files from SD and puts them back on Flash.
So, that would be a great practice to backup prior to update and then restore if needed.
3 Likes
So I updated today, as stated above. Since I transplated cnc I am trying to square right now
Just found probe function works until it is supposed to retract. Retract did not work, I had to manually move off of my touchplate.
2 Likes
Warning, there’s a caveat to this. Backup backs up all flash files to SD. If you do multiple backups, it will include all filenames that you ever backed up. So, you might be restoring more than you want to. I’ve used the backup before, and at one time, I had a version of an extension without the .gz file extension. Later backups backed up the .gz version. So, when I restored, both files were included and the old version without the .gz extension took precedence when loading. Deleted the non-gz version and all was well, but this isn’t foolproof.
2 Likes
So now the preferences file, at least for UI V2, is named prefernces2.json why the heck would that change?
I made some edits and hit save, got the new file name. Deleted both, power cycled, made some edits saved, still got prefernces2.json
2 Likes
Huh? I thought the file is preferences.json for both v2 and v3, which is confusing in itself since they aren’t compatible with each other. Are you saying that’s not the case anymore?
Edit: You’re right. That’s weird. This is where it gets confusing when they just update the index.html.gz file in the FluidNC repo. I’m not sure where that is coming from.
1 Like
It looks like the WebUI v2 build is coming from the revamp branch on Mitch’s fork:
Check out this commit: Preferences in preferences2.json with fallback to preferences.json
1 Like
ha, that’s funny. I was thinking about doing that for v3…
So what would we name the preferences file for webui v3?
Shoot, that also means my configs are now going to be 3.9.1+ only. Crud.
I can take it out all together but setting some travel speeds is pretty nice. I also am not sure what we should have for polling anymore.
Pulse_us seems fine at 2 So far.
It should still load preferences.json, it will just rename it if you save from the UI, I guess. It would have been better if he saved reference to the name that was used to load it, and always used that
For WebUI3, we don’t need to rename it if he’s already done that, but I’ll ask him if he wants to. Better to do it now than wait til it’s officially supported and cause more havoc
2 Likes