Advanced Search

Q is a segment decimator. Setting it to 0 disables it. In the older tp it had to be set explicitly every program as the default was something useless. In the current planner the default should be 0 already. I wonder if you accidentally changed it somehow globally.

I have no clue why you saw that or what it means... another of life's mystery's I guess. And oddly enough the spell checker is working here.

JT

I used the image from this page. The only other thing I added was Filezilla, to transfer files to and from my PC where I generate the gcode files.

And yes, pressing Ctrl-esc brings up the main rPi menu where I can select to run other applications. If I have LinuxCNC up, I can use that to launch Filezilla without exiting LinuxCNC. That functionality has to my knowledge always existed in the image.

Is this OK or any better idea?

You might set the MIN_FERROR larger when tuning:

MIN_FERROR = 0.005

@ihavenofish,

how does it deal with tangential motion that exceeds acceleration abilities?
We calculate the max segment velocity based on curvature extrema and maxacc.
The implementation of this funtion is here.

I agree that deviation is the key. And the possibility to blend out multiple segments respecting path deviation.

Concern:
Today i experienced unwanted interpreter behaviour. I did know the problem was there, but forgot about it.

1. When no G64 Q[x] value is given, the interpreter removes tiny segments on it's own, replacing arc's with line's etc.

In the case of our planner, we have to always use the combination G64 P[x] Q[0.0] to prevent this behaviour.

This behaviour can also been seen on page 3.
The examples made by Hmnijp used no G64 Q[x] value. And planner did remove segments on it's own,
replacing arc by lines etc. Trimmed segments are clearly off path, wich is not ok.
It shows exactly the problem. If Hmnijp used a G64 Q0.0 value, the result would be very different.

Now i added this as a note to the planners readme file, that users including myself are aware of this, and don't forget about it.

With no G64 Q[x] value, we get unwanted interpreter input:
 

Using G64 Q0.0, we get what is to be expected from interpreter:

Thanks Pete,
Have looked at the trace with a scope now. The 0.1uF smooths out the sawtooth, but I still have this variable voltage flicker that's not caught on the meter, so something adrift with that power supply I think.

Yeah I'm no too sure about that.

Where abouts in Oz are ya.

zz912 wrote:

Do you think the location of the template configuration files is different for 2.9 and 2.10?
 

No


So I don't get what your problem is..

guten Morgen,
ich setze derzeit eine LuxTurn Drehbank auf. Anders als meine bishrigen LuxTurns erhält diese einen Glasmaßstab auf der X-Achse.
Dazu verwende ich LinuxCNC 9.3, eine Mesa7i96s und eine 7i85 für den Encoder Eingang.
Die ist mein erster Versuch, einen richtigen closedloop Regelkreis herzustellen und ich verzweifle an der erforderlichen Einstellung der Regelparameter.
Alle Videos und Dokus zeigen Werte von P mit ca. 10, FF1 01. und FF2 0.0001, und zum Start FF1 und FF" erst mal 0.
Dann fährt bei mir die Achse nur einen ganz kleinen Weg (Bruchteil von mm) und meldet Positiosfehler, auch bei ganz kleinen Geschwindigkeiten.
Mit dem Herumspielen von P, Accelleration, FF1 konnte ich die Achse dann soweit bewegen, dass ich im HALScope den X-error minimieren kann.
Der ist jetzt eigentlich schon recht gut (<0,02) aber nur, wenn FF1 ca.1 ist. Trotzdem meldet beim Beenden des Verfahrweges Linux wieder Motor Positionsfehler. Wo muss ich da noch angreifen? Solange P und FF1 falsch waren, sah man den X Error ansteigen und bei       Erreichen von 1 kam die Fehlermeldung beim Verfahren. Aber hier ist der Fehler ja nur noch minimal und trotzdem kommt die Meldung. Liegt die Ursache ganz woanders?HAL, INI und Bildschirmaufnahme anbei
Wäre toll, wenn jemand eine Idee hätte
Rainer

I haven't tried it yet. But I think if this computer isn't good enough, I should try a new LAN card or even a new PC. I already have a hydraulic chuck and an additional servo motor waiting to be installed. The plan is to be able to mill on the lathe. I want to have a fast servo thread

I can't explain why there are such delays in internet communication. In many places, I see mentions that a servo thread of up to 4 kHz is possible on network cards.So, should I try a new network card first?

Ok, so I have the M101 and M102 functioning correctly. It is set as disabled on startup and can activate and deactivate with MDI code in Probe Basic with M101 and M102.

I have used the Template Main to create two buttons. "Edge Probe - ON" and "Edge Probe - OFF", and have them connected and alternating active on selection.

BUT, I cannot find any instructions or examples on how to create the connection from the buttons to the M101 and M102 files so that they can be run on click. Does someone have an example of the process that is used to activate the connection to the M-code files created and stored?
 

Assuming the Mesa 7i92 is my answer, I'm in Australia, I looked for a local distributor and a 10 year old post on CNCZone from rodw said that he too was Australian and had them for sale?? Is this still the case and how do I go about buying one?

Ethercat will work with Ethercat servo\stepper drives and other Ethercat devices, unfortunately my endeavors and experiments have been in other areas.

Linuxcnc comes with a plethora and sample & simulation configs, but what you want to do may not be even possible or may require more work than you've assumed. Have you explored the Linuxcnc menus, tried a simulation config, read the Linuxcnc docs ?
Did you even bother to have a look at the 2 links I gave you ? One of them explains the reset function.
When you try to run a config that you think will work what errors if any are you gettting ?
Are you getting any output at all ?
Have you got access to a logic analyser or 'scope ?

Does Ethercat hardware support updates every 25000ns, as this would have to match the base thread timing. Otherwise the steppers are going to be very very slow with updates every 1ms.

The best bet would be just to get a single axis moving, as a proof of concept and evaluate the performance.

There is a lot that you may have assumed & expected that may not be the case or possible.
Tho it does sound like a reasonable & unique idea, but I think you may be delving into unknown territory. So you make have to come up with a lot of solutions on your own.
No one would try and shut you down, but there maybe more hurdles than you realise.
In honesty I don't see how it would be an improvement over an external board that generates step & direction timings. Or an ethercat driver servo/stepper driver.

Sounds like you want to use this IO board to drive Step/dir signals for a stepper motor driver.
It will work kind of but you will be severly restricted by the slow speed of the servo thread. 
Say 1 ms servo thread, which is normal, and you will get max 500 steps per second. You will need 10 times more than that, easily.