Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot run install scripts #726

Closed
WaynePauly opened this issue Nov 28, 2022 · 14 comments
Closed

Cannot run install scripts #726

WaynePauly opened this issue Nov 28, 2022 · 14 comments

Comments

@WaynePauly
Copy link

Controller Board

ESP32 DEV V1

Machine Description

Just ESP32 for now; will go in a 4 axis mill

Input Circuits

No response

Configuration file

stock file

Startup Messages

Every time I start an install script I get a esptool failed; cannot find the path specified message.
Any suggestions? Wayne

User Interface Software

No response

What happened?

error message in install

Other Information

image

@bdring
Copy link
Owner

bdring commented Nov 28, 2022

Be sure that the zip file is extracted into a folder. Run the scripts from that folder. If the folder requires administrative access open a terminal with admin rights.

@bdring bdring changed the title Problem: Cannot run install scripts Nov 28, 2022
@WaynePauly
Copy link
Author

WaynePauly commented Nov 28, 2022 via email

@MitchBradley
Copy link
Collaborator

USB will still work with Bluetooth.

I do not know what you mean by "the Main folder".

@WaynePauly
Copy link
Author

WaynePauly commented Nov 28, 2022 via email

@MitchBradley
Copy link
Collaborator

If you want to use the prerelease "-pre4" version, download https://github.com/bdring/FluidNC/releases/download/v3.6.5-pre4/fluidnc-v3.6.5-pre4-win64.zip , unzip it, and follow the instructions in HOWTO-INSTALL.txt therein.

To use the latest released version, do that with https://github.com/bdring/FluidNC/releases/download/v3.6.4/fluidnc-v3.6.4-win64.zip

Your prior knowledge of Grbl_Esp32 may be causing you to assume a different process. For FluidNC, it is hardly ever necessary to obtain the source code and compile it.

In future questions, please be very specific about exactly what you got and where you got it from. "... zip files" is not specific because there are several possible zip files, including source zips obtained from the main github page, release bundle zip files from release pages, and source zip files from the release assets sections. For easy install, you want the release bundle per the links above.

If you have trouble with online videos, we need to know which specific ones.

@MitchBradley
Copy link
Collaborator

@MitchBradley
Copy link
Collaborator

Does it work using the procedure given above?

@WaynePauly
Copy link
Author

Yes, somehow I got off on the wrong foot, thanks for the help.
I am finding some compatibility issues with other programs though: I can send serial bluetooth commands no problem, but I cant find an android app that does work, particularly GRBL_Controller. Know of any tested ones?
Also UGS runs fine but only displays metric and after changing to Display Inches:true in the yaml it doesn't display any numbers except zeroes; any ideas there? There are no firmware settings so you can't set $13=1.

@bdring
Copy link
Owner

bdring commented Dec 3, 2022

I have used several android apps over Bluetooth including Grbl Controller and some terminal apps. It is a bit advanced to get the BT serial port setup properly. I suggest using USB until your are more familiar with FluidNC.

Many people use UGS successfully. You should ask on the UGS forum if you have problems.

@MitchBradley
Copy link
Collaborator

With UGS Platform 2.0.12, using the FluidNC Firmware setting, I got it to display the DROs in inches with the Jog Controller and the Pendant:

image

report_inches affects the communication between UGS and FluidNC, but does not appear to affect the display. I looked at the UGS source code, and from my reading, $13 in Grbl mode behaves the same, affecting the backend communication but not the display. @breiler - am I missing something?

@MitchBradley
Copy link
Collaborator

I'm closing this because I don't thing there is anything more to be done from our end.

@breiler
Copy link
Contributor

breiler commented Dec 3, 2022

I have to look at how we read the units settings from FluidNC, there is probably something missing...

Historically this has been very messy, trying to juggle all variants of units being used (the reporting units from the controller, visualizer units, jog units, setting units, gcode state (G20/G21)).

To solve this we try to assign a unit to any coordinate being used, for instance when parsing the status report and have one setting for the units. For the end user, they should only care about the units settings in UGS like in the screen shot you posted. But something is obviously not working so I have to have a look at it.

@MitchBradley
Copy link
Collaborator

@breiler UGS appears to be handling the reporting from FluidNC correctly, i.e. regardless of the setting of report_inches and thus the numbers that appear in the <...> report, the DROs scale that and display the correct mm value. By clicking on either the pendant units button or the Jog controller units button, the DRO displays change to the other units. Thus the reporting units and display units are independent. Is that how it is supposed to work, or is there another setting somewhere to change the DRO units?

In my tablet UI, the reporting and display units are also independent, but I use the G20/G21 modal state to determine the displayed units. The display units change on any modal change between G20 and G21, based on the $G report value. The idea is to have the DROs track the GCode values.

The only thing that appears "wrong" is that, when you click on Jog Controller > Millimeters, the legend on that button does not change, although the DROs do switch units. The legend on the Pendant > Units button does change, from Units: MM to Units: INCH and back.

@MitchBradley
Copy link
Collaborator

My recommendation is to leave report_inches set to false, and senders should not infer display units from the reporting units. It would have been better if Grbl did not have the option to change the reporting units. That feature was perhaps useful with early dumb senders that are not much more than serial terminals. With modern senders, it is better (less to go wrong) to always report in mm, and let the sender choose display units by other means. The modern senders that I have studied tend to control the display units and reporting units independently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants