thiagoralves / OpenPLC_Editor

OpenPLC Editor - IDE capable of creating programs for the OpenPLC Runtime
GNU General Public License v2.0
429 stars 207 forks source link

Arduino dialog intuitive serial port input #123

Closed joluxer closed 3 months ago

joluxer commented 3 months ago

Rearrange the Arduino upload dialog slightly, so board and port remain visible across all tabs.

The serial port is memorized by its path, not its name. If the user enters a path on his own, this accepted as it is and just used. It is left to the user to enter a valid path, if he does not use a serial port from the drop down list.

This way also serial ports, that are not or cannot be known to pyserial are also usable, such a pseudo terminals, virtual serial ports, that are mapped across network, files on PLAN9 filesystems, etc.

The settings of all three tabs are saved to settings.json for reuse on next dialog startup.

IO configuration settings from the user are not longer stored into the hals.json, this information moved to settings.json too, as the HAL information file should be data that is provided by the OpenPLC framework and not be modified by user action.

The Arduino build output comes now in continuously while the builder processes are running in the background, so the user is not left alone with a stalled output window. Long running actions have visible live output now.

The Arduino upload dialog and its builder in the background are now prepared for I18N. Support for translation is welcome. Maybe I do one day the german translation part myself. Time is on.

thiagoralves commented 3 months ago

Awesome PR! Thanks @joluxer! Could I just ask you one more thing since you’re already working on the Arduino builder dialog? How about having the hardware settings (Modbus, WiFi, IO config, board selection) stored in the project file instead of a global settings json? Then each individual project will also contain information about the hardware they were built for.

joluxer commented 3 months ago

Glad that you ask. Your question is welcome and you made my day. The final part of this PR and this branch, where the settings.json receives all project specific values, is actually the preparation for the step you ask for. My next PR will contain exactly this turn. In my fork is already a branch visible with the name arduino-settings-in-project. This branch moves the global settings.json into the project as arduino-settings.json. I did not yet call the next PR, because I learned in other projects not to do multiple consecutive PR at once to avoid confusion. And the current PR is already somewhat between large and huge with some commits kind of off-topic. So stay tuned.

thiagoralves commented 3 months ago

Perfect! Thanks again

thiagoralves commented 3 months ago

This PR seems to be causing problems for some people. See https://openplc.discussion.community/post/compilation-failed-on-esp32-13449349?trail=15

Is it working for you on ESP32 and other boards? Perhaps could it be the new arduino-cli the culprit?

joluxer commented 3 months ago

I'll have a look on the issue today, thanks for the feedback.

joluxer commented 3 months ago

As this PR is already on the master, I'll create a new branch off the master for the issue and a further PR for the solution.

thiagoralves commented 3 months ago

Ok, thanks. I’ll go ahead and merge your other PR so that master is in sync with your latest code

joluxer commented 3 months ago

I found a solution for Linux/MacOS, that makes the process handling reliable.

The remaining problem is the windows world, where pipes are always blocking. There is a lean solution possible, when using the pywin32 package. This requires the installation of this package using pip or simelar, when installing/creating the venv for the OpenPLC editor.

@thiagoralves : Would you hesitate to integrate this? Beforehand I would do the testing on my Windows environment using manually installed packages.

thiagoralves commented 3 months ago

Can you make the windows version blocking as it was before for now? Integrating another package requires a new installer to be generated, which is a bit of a hassle. I'm willing to do this, so keep the non-blocking code on a separate branch to be integrated later once the new installer is ready. For now, let's just fix the build so that users can compile code on Windows again.

joluxer commented 3 months ago

Yes, I can do this. Users need a fix. Let's go this way.

thiagoralves commented 3 months ago

Awesome! Thanks again @joluxer