Advanced Search

Thanks for the answer. Is there no way to operate my machine like this?
One option would be to swap the X and Y axes, but is there another option?

For Mesa step generation (others are similar) LinuxCNC creates a local feedback loop
where at every servo thread invocation, LinuxCNC reads the current stepgen position
and then sets a new velocity based on the current commanded velocity and with a small
correction based on the current position error. That is, at every servo thread invocation,
LinuxCNC generates a new position. Based on that new position and the current stepgen position
a new velocity is calculated to meet that new position at the next servo thread invocation.

With Mesa hardware the precision of the control loop is 1/65536s of a step, so typically
the error between the commanded position and the stepgen position is never more than
a fraction of a step.

Here is a plot of stepgen error at:

10 ms servo thread
1 IPS cutting speed
5 IPS rapid
50 IPS/S accelration

Note that Velocity is in IPS  per division and error is in 20 uinch  (~0.5 u) per division

The residual noise in the error is caused by timing uncertainty in the position sampling.
This is about 2 usec at a 10 ms servo thread but about 400 ns at a 2 ms servo thread

 

Even the chord error is nothing to worry about as long as you do not have extreme
acceleration (say > 1G)

 

This is how the interface looks like.
 
The difference, the contrast in style is obvious.
So I think with a QT interface, as you are doing, it would be better.

Giovanni

Yes it's a lot of work but it will be all QT.
You have to change at least all the interface.
That's a very good job.

"My" (note the quotes, cause it's not mine) version, the solution I proposed in the message above it's only the "standard" gtk-tkinter version for python3 in which I disabled the exit to sys if the screen is not axis, gmocappy... etc. allowing to be used with qt_dragon interface.
The empty Ncam tab is only to launch NativeCAM with LinuxCNC.
It's meant to be only a temporary solution if someone really need to run it.

Regards
Giovanni

I just released version 1.2.1 of Flex GUI which includes Axis style controls and an example of Axis style GUI using Flex GUI.

JT

I tested it. (Updated dialog_widget.py and macro_widget.py)
It works fine, but only with the "load" button. If I want to save the settings, it's the old way. (path from qtdragon.pref)

I think it would be better to always use the path defined in the macro file. Then each macro can collect its different settings in a defined directory.

If it's a lot of work I wouldn't bother. Either I will finish the qt version or adapt your version.
Qt version seems to mostly work, but looks slightly different:

 

 

Does the sample basic spacer work for you?
Also the turners cubes I can't get to work (flat verse diameter error)

Chris

PCW wrote:

With Mesa hardware (and most external hardware step/dir interfaces
or even EtherCAT drives), the velocity (step rate in this case) is updated
every servo thread.

This means that there is a constant velocity between updates. This constant
velocity means that that you will  have a small error (chord error) between a
desired curved path and the actual (linear interpolated) path.
 

Okay, that's interesting, and of course I have more questions.

First, does the Mesa know how many steps it should count?  Will the longer period introduce greater error in the length of each chord?  I.e.,  might it overshoot by 1ms worth of steps, vs. just 500ns worth of steps?   Or is the command to the Mesa really just "start moving at N steps/second"? (rather than "start moving at N steps/second, for 10500 steps")

Second, the chord error you describe would only occur for a curved path.  If the G-code is written completely using straight-line approximation (which of course introduces its own chord errors), it seems like the longer servo period wouldn't introduce any more error at all.  True?

In any case, it sounds like I can stop worrying about my 2ms servo period for the time being.

paul

For a 7i96 spindle you have to add that manually at this point. Now that the 7i96 is back in stock I might work on adding a spindle to it in MesaCT.

Watch the output pins as you toggle flood and mist in the halshow program.

JT

macrotab will now honour these entries in MACEOOPTIONS:
default:default.txt
path:~/linuxcnc/nc_files/macros

You can set them to any valid name.path you like (filename must end in .txt)

Do you think it would be nicer to use this path the very first time then use one from the preference file? This would make it remember the last used path rather then always using the one defined in the macro file.

I prefer the ice40 when I need more pins, e.g. the Devantech iceWerx iCE40-HX8K.
it has the advantage that it can be used with the opensource toolchain.

otherwise the tomverbeure.github.io/2021/01/22/The-Col...velopment-board.html is also pretty cool

Since a QT version is currently in development, I think it would be better to use that version for QT interfaces.whithout making strange combinations.

Regards
Giovanni

There is a slowly developing version for qt screens:
github.com/LinuxCNC/linuxcnc/commits/qt_ncam/

One more correction would be useful.

In the macro file there is such an entry as path:~/macro,
I think that it should be the directory where configurations are saved and from where they are read. Instead, it always opens the directory from the "last_loaded_directory" entry in qtdragon.pref

> 2. Where are the videos ?

Coming soon. Our 4G cell service and broadband internet went down for nearly a day :|