[BUG] Auto_Build.py failure on BOARD_BIGTREE_SKR_V1_3

[sbaeder]

15488 # Bug Description

In trying to cleanly set up for the official 2.0 release, using VSCODE, I reinstalled the vscode extensions for marlin. I got the icons, etc. When using the default configuration (RAMPS based), it pops up the window as expected. But with BOARD_BIGTREE_SKR_V1_3 and other boards ( I tried a few of the other 32 bit ones), I get a strange failure.

My Configurations

Configuration.zip

Steps to Reproduce

just try to use the build step. If I change to the default ramps - works (and pops up)

Expected behavior: [What you expect to happen] thought I might see a pop up (as with other boards)

Actual behavior: [What actually happens] Got a failure message and a blank tk" windows.

Additional Information

fail.zip

• Provide pictures or links to videos that clearly demonstrate the issue.
• See How Can I Contribute for additional guidelines.

[shitcreek]

I cannot reproduce this error with any board compiling RC 2.0. With SKR 1.3, there should not be any popup. Is your python configured properly? https://code.visualstudio.com/docs/python/environments

[thinkyhead]

Not just RC. Totally R.

[thinkyhead]

I get a strange failure.

@shitcreek has seen that. Upgrading the OS (and thus Python) fixed it for him. We'll keep an eye on this to see if there's a more direct fix without needing to patch Python.

[boelle]

do we need to keep this open?

[sbaeder]

I think it is (it has always worked in the past OK, and builds OK with using the platform.io commands to do it (changing the default manually).

I'll double check when I get home later, but the version I have is listed as part of the log...inside the fail.zip, inside the fail-log.txt, is says it is python version 3.8.0

So, that should be newest - right? and I don't thinnk I did anything special. As I said, for me, it works as expected if the board is one that needs a pop up, but fails when it doesn't need one. I don't know enough python to debug fully, but I do know it extracts the board and the type correctly (I added some print statements).

I can try a re-install of python...

[sbaeder]

Note: the 3.8.0 is the latest version released. So do I need an "older" version? Or can you try to verify with newest python?

[sbaeder]

Sorry - didn't mean to close...Hit wrong button....

[shitcreek]

This article here might help: https://code.visualstudio.com/docs/python/environments

[sbaeder]

OK, while that link doesn't cover this, the "getting started" link points to the VSCode extension for python, and that extension says that it supports up to 3.5...but example graphics list 3.7.0 ???

BUT as I said above, the most current production release is the 3.8 version. SO, I'll try this with the older version and see what happens.

OK - Closer read says GREATER than 3.5 Doh.....

[boelle]

latest is not always the best, i have a rule of thumb, why update if it does not bring anything new and very needed

example, local pizza delivery have their site hosted, and the hoster like to update to latest all the time without giving an option to downgrade via htaccess, result: site is now broken

site has run without issues for years and everyone is happy

with a simple downgrade option in htaccess they could have been done with it in 5 mins or even had the downgrade done beforehand

morale of story is, dont update without thinking for yourself, latest is not always the gratest, and sure not without a boatload of work to update things to work with the update

[sbaeder]

Yes - I also agree. But as a new user, and following directions to go get the python from the download page, you would go (as I did) to the default which is the 3.8 version. Just like the Marlin page now direct folks to the 2.0 release.

So I didn't "update". I just installed. By the way, just tested default "RAMPS" board config, and if I let it continue past the pop=up for memory, it also fails when trying to spawn the build output...

But, lets see if it works with 3.5... and others - I'm cleaning ALL things python out, and starting cleaner...

[sbaeder]

OK - I totally removed all python AND visual studio code.

Steps to reproduce

1. install Visual Studio Code
2. Attempt to install platform.io - didn't have ANY python installed at that point.
3. installed python as directed by platfor.io (i.e. LATEST VERSION - a.k.a. 3.8)
4. Completed install of platform.io
5. installed Marlin AutoBuild folder to VSCode extensions
6. Ran Build - FAILED
7. Installed python extensions so I can select version of Python
8. Installed 3.5.4 version of python
9. Ran build - FAILED
10. Repeat with 3.7.5 - FAILED again.

So, (and not trying to be snarky or anything...) But what version of python is this working with (inside VSCode) for all of you?

[sbaeder]

New Text Document.txt

log files of some recent attempts on even v2 of python.... Seems to fail when trying to run some noe proccess

[boelle]

@sbaeder since 2.0 was just released a few days ago has this changed this issue at all?

[sbaeder]

@boelle Not that I know of, since I never really tried it this way before - always used the manual method to change the .ini file to default to the right platform default. With proper 2.0.0 release, I thought I would give it a try (and not having to modify the ini is a PLUS).

With my simple debug skills, I can see it finds the right platform from the configuration and pins files, etc. It properly figures out if it needs to pop up something to ask user, and then, when getting ready to spawn off the actual command to do the build, etc. is when it fails.

I may keep plugging away at that part, but it is a bit beyond my current knowledge...I have no clue at this point in time. If it isn't a python issue, could it be a windows 10 issue or something else (especially if this is working OK on other platforms (linux, mac).

Scott

[sbaeder]

OK - maybe this helps - but, in trying to add some prints and other rudimentary debugging, it has something to do with the section of code at the end that trys to run the platform.io code.

# Re-use the VSCode terminal, if possible if os.environ.get('PLATFORMIO_CALLER', '') == 'vscode': print('reuse') sys_PIO() else: print('new window') auto_build = output_window() auto_build.start_thread() # executes the "run_PIO" function auto_build.root.mainloop()

When I use the build button on the extension, it still winds up going to the "new window" section, and hangs. I added some code I found to print the environment variables, and I don't see one for "PLATFOMRIO_CALLER" so it is not trying to just run the platform.io command.

Even if I try to "fake it out", I don't get the platform.io command to run, since there is no command line platform io in my path.

Could this be the issue? I don't (haven't ever) use it in the CLI mode - always the GUI from VSCode.

[sbaeder]

OK...Reading the platformIO docs it says you do NOT need to add it to the path, since you should use the terminal inside the IDE - BUT if you want to use it stand-alone you can do that by manually adding the PATH.

Not sure there was any docs at all that suggested we needed to do this in Marlin, BUT when I did add the path, it works as expected (given the above). i.e. a new TK window opens and it runs as expected.

But it seems to me that the means of detecting if inside platfornIO and just issuing the commands (which also fails if there is no platformIO in the path should work.

I'm still going to play with this a bit more.

[brew99]

I’m running into the same error as you. I have not used auto build before so am struggling and am not a programmer. I hope you are able to figure this out. I’m on python 3.8, vscode with PlatformIO, win10 and bugfix-2.0.x from a nov 6. I’m using a SKR mini E3

[sbaeder]

By adding code to dump env variables from the scripts point of view, I found that it looks like the env variable for 'vscode' (in 1.4.2) is now called 'TERM_PROGRAM' and not 'PLATFORMIO_CALLER'

However, without the platformIO in the path, this will also fail in the code that starts the command to build with the right parameters.

This means that IF we add the path to platformIO, it will work as expected, just not reuse the window when it is really in vscode.

Not sure why the platformIO buttons to do a build work, but they execute a fully pathed executable name when invoking the build.

So, Short term "fix" - add the platformIO path as described on [https://docs.platformio.org/en/latest/installation.html#windows] which tells you to add it to the path (for windows). This might be a windows thing, not sure.

Longer term, there is an issue to "fix" here, since it is not required to use the CLI (except from a command/terminal window (using PowerShell) when using VSCode on windows 10

p.s. IF we should close this and start new bug tracker, that;s fine with me...

[sbaeder]

OK - sorry to drag on, but here is more information....there are (at least) different "terminal windows" when using VSCode, and I think that the marlin build extension is getting the wrong one. Maybe due to updates in vscode???

To verify, a "new terminal" from the top menu on VSCode lists it as "powershell". It acts the same as the "Marlin Build #1" window, but NOT the same if you use platformio under quick access to open a CLI or even a terminal.

To verify this, with NO Marlin folder open, run a Marlin Build command. It will fail, but leave a terminal open. Also open a terminal (powershell) from VSCode, and a terminal from platformio (PlatformIO)

you can verify that the ENV variables are different (which is why the check for vscode is failing), and the path is different - i.e. platformio is found in the shell created by platformio, but NOT in the one created by the marlin AutoBuild process OR the powershell terminal created by VSCode.

this is verified by just entering in platformio -h The powershell and Marlin Build terminals fail, but the one fro platformio gives help messages.

So, the root cause of this failure (across the board on ALL boards) is that the autobuild is not getting a platformio terminal when it creates it's environment to run.

[ManuelMcLure]

Check to see if there's a little bell icon in the lower-right corner of the VSCode window - there is a message that sometimes shows up the first time you bring up a PlatformIO terminal asking whether you want to allow it to update the environment.

[sbaeder]

yes, but NO NEW NOTIFICATIONS on a clean re-install of everything. Note: the default platformio build works fine, and the AutoBuild works fine EXCEPT it can't find the platformIO command to execute, and it can't properly find out if it is from 'vscode" because the env it uses is not present. It needs a platformIO cli terminal to work.

I have dug pretty deep on this already, but don't know what the platformio buttons are doing to get a "good" cli, but if you use them, you will also notice that they use a full path to the executable...

inside auto_build.py (in the atom space), it just uses the os.system command to run the process. What I am saying is that isn't sufficient, since a platformio terminal has several other things set (in addition to PATH).

[sbaeder]

the more I look at platformio, isn't this just best handled as some sort of "extra_script.py" type of thing, that can over-ride the platform so it always gets the right one as the "default" based on the configuration.h? Didn't know if this should be discussed somewhere elase or ??? (just let me know). While all new to this, it seems that the platformio folks planned for things like this, and it seems a bit convoluted to do something in VSCode that then points to an "atom" script.

[boelle]

tried to hit the trash can icon?

or delete these 2 folders?

prob will not change a thing but hey it could

[sbaeder]

I did start with a completely clean install of vscode and platformIO as also the marlinn dir, but I can try that again. As far as I can tell, there is some difference on windows that is not putting the platformIO in the path by default, and if you use the vscode "new terminal", you get one thing, and if you use the platformIO "new terminal" you get another.

I haven't found a way to figure out how vscode gets all the targets from reading the platformIO (ir more properly stated how platformIO reads the .ini file and creates / registers all the targets. If there was a way to do the parsing of the configuration.h (and other files), and THEN invoke the right target (already registered to vscode), that would be more ideal. But I can't seem to find any API call that retrieves the list of all the targets...

I'll edit this to add if it makes any difference as requested, and am open to trying anything else....

[sbaeder]

OK, did one more set of tests, and clearly it is related to the terminal that is created by the AutoBuild extension. So, I'll close this, and seeing that this is now moved to it's own repository, I'll file an issue on that there.

Scott

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.