[hansu]

Fixes #3238 and #2335.

To be done

• Adapt Gmoccapy - change spindle => spindle_0 in *.ini files #3488
• Update sample configs for DEFAULT_LINEAR_VELOCITY [TRAJ] -> [DISPLAY]
• Increase INI file version and set up update-ini script

[zz912]

* [ ]  Adapt [Gmoccapy - change spindle => spindle_0 in *.ini files #3488](https://github.com/LinuxCNC/linuxcnc/pull/3488)

Feel free remake (or close) #3488 how you need. Git is not my friend, so I cant help you.

#3488 also does:

• INI file from PNCconf is more verbose in build_INI.py
• correct MACHINE in 7_axis.ini
• correct MACHINE in 6_axis.ini

[andypugh]

update_ini is designed to be scriptable, (-d and -f flags) and I think I had a meta-script that ran it on all the sample configs.
I probably can't find it any more, but I could have a look.

[hansu]

update_ini is designed to be scriptable, (-d and -f flags) and I think I had a meta-script that ran it on all the sample configs. I probably can't find it any more, but I could have a look.

Yes that would be helpful. I only used tested with the -d option so far.
The renaming stuff is done so far, only some parts which moves or copy some values are missing.
And a bit refactoring maybe.
Also a little bug where it generates two [KINS] sections...

[andypugh]

Yes that would be helpful.

Sorry, I looked and it's nowhere obvious. It might be sat in a git stash somewhere, but I think it's probably been lost.

I doubt it was anything special, I am not much of a scripting wizard.

[hansu]

I copied now

• [TRAJ]DEFAULT_LINEAR_VELOCITY -> [DISPLAY]DEFAULT_LINEAR_VELOCITY
• [TRAJ]MIN_LINEAR_VELOCITY -> [DISPLAY]MIN_LINEAR_VELOCITY

The values are/will not be not used in TRAJ any more. Do you think we should delete them from TRAJ or keep them as a precaution ?

[c-morley]

Ate you sure they ate not used in the trajectory planner?
Iirc they are used in non trivial machines.

[hansu]

Ate you sure they ate not used in the trajectory planner? Iirc they are used in non trivial machines.

DEFAULT_LINEAR_VELOCITY I overlooked, but MIN_LINEAR_VELOCITY is couldn't find in the trajectory planner.

[c-morley]

Ahh yes DEFAULT is what I was recalling.

[hansu]

I think the script is ready for the first review.

@andypugh How do we handle the message boxes if upgrading from <1.0 to 1.2?
Is it too irritating when there are multiple LinuxCNC versions in the list like this?

[zz912]

Hi Hans, when do you expect to finish this PR? I'm currently converting the spindle control from PWM to hm2_modbus. So I could test if there are any bugs when changing SPINDLE => SPINDLE_0.

[hansu]

It's more or less ready from my side. This is waiting for a review and then all the INI files needs to be converted by the update_ini script and committed.
But this will be done just before 2.10 is being released I guess.

[zz912]

I asked the wrong question.
When do you expect to merge this PR to master?
I'm currently working on hm2_modbus communication.
If it were merged in a few days. I'd wait for that.

I'm just asking. I don't want to do it twice.

[hansu]

I think it will take some weeks

[zz912]

Ok, thanks for information.

[andypugh]

I think that the very long message box is fine. We really want users to be aware that a lot has changed, and to think before pressing the buttons.

[BsAtHome]

How does the update script handle #INCLUDE syntax?

The include handling is expanded by the linuxcnc script and you don't really see the whole truth when running. Well, until now, because the new INI parser does the include internally and does not rely on external merging.

But still, the update script should be aware of #INCLUDE directives and act accordingly. Maybe there needs to be an additional interface in the new INI parser to extract filename/linenr information from python (already possible in C++).

[BsAtHome]

The update_ini program also needs to update quoted strings (see #3946 and #3947).

The new ini-parser in python allows you to recall the exact file and line of any variable by using linuxcnc.ini.lineof(section, variable [,num]) (returns a tuple). This allows you to read the old ini-file as text, converted into an array of lines, and then change any line accordingly. The reason to use this feature is because #INCLUDE statements skew the program's view of the content, but the original source of variables can still be recovered by using lineof().
A small problem is line continuation, which are not recoverable from the parsed value (was merged into one value). However, I don't think that lines with continuations are lines that generally need change. But, it is possible to look at the previous line in the source text and see if that had a continuation and act accordingly (lineof returns the last line of the continued value).

[hansu]

@hansu @BsAtHome How is this going? The last note here was about a rebase and handing it over, back in June.

I waited for and answer, but however, I rebased and it's ready for taking over.

I ask because halfileupdate (#4499) is in master now. It converts the HAL files an INI lists after the 2.10 component, pin and type renames: a diff by default, -i rewrites and keeps a .bak. Bertho said on #4499 that the update script could call it for the 1.1 to 1.2 upgrade, and this PR is where the version goes to 1.2.

Would you like that in here, or should I add it once this is in?

I think this fits good here.

[gmoccapy]

IMHO this is not the way to go.
All spindle stuff should move away from display and should be centralized for every GUI in [Spindle] section but not in display.

Gmoccapy is gtk based and should never depend on QT stuff!!!!
We get qt errors on start of an gtk gui, I hate that!

Why we get an "no angular velocity error" if we do not have an angular axis in our GUI.

Unify stuff is OK, but not this way, at least that's my opinion.

Norbert

[KentChenY]

test

[KentChenY]

Apologies — the previous "test" comment was posted by mistake from an automated session (wrong tool invoked). Please disregard / feel free to delete. No offense intended to the maintainers of this PR.

[grandixximo]

Apologies — the previous "test" comment was posted by mistake from an automated session (wrong tool invoked). Please disregard / feel free to delete. No offense intended to the maintainers of this PR.

Could you share some light as to what these tests are about? what automated sessions you run, and how can they post randomly in our repo? It feels very uncomfortable from our end receiving these test messages.

[hansu]

IMHO this is not the way to go. All spindle stuff should move away from display and should be centralized for every GUI in [Spindle] section but not in display.

The Spindle section should control the spindle hardware, so set the physical maximum speed e.g.
In the display section, there should be the values that control the GUI, so min and max displayed speed and the default speed, like it is currently controlled by the gmoccapy settings page.

Why we get an "no angular velocity error" if we do not have an angular axis in our GUI.

That should be fixed in this branch.

[grandixximo]

A reminder, the #INCLUDE we better list them to the user that they need update

BTW we are the meeting