Advanced Search

Normally you would set this so it never gives errors in normal operation
(since stopping on a following error is catastrophic )

I'm trying to reach 10000mm/min max velocity on three axis, but lowering STEPLEN and STEPSAPECE below 1000 nanoseconds, following error shows up immediately.
Based on driver specs Maximum frequency of input is 1MHZ (Differential motion).

I believe mesa 7i95T isn't limiting factor here!?

My current values:
DIRSETUP          = 200
DIRHOLD            = 200
STEPLEN            = 1000
STEPSPACE       = 1000
SCALE                = 2000

 
 

I put it up to 0.1 and got no error messages any more. So I will slowly reduce it to see when the error comes up again.
Thanks a lot

I'll try to recap the previous posts. What I want to do can be done in multiple ways.

1)my first original plan.
Create new files in the linuxcnc/src/emc/usr_intf/pncconf folder and then copy them to the new LCNC configuration using pncconf.
I could do this. It is not problem for me.

2)However, @Aciera came up with a better idea.
He doesn't want to create new files in the linuxcnc/src/emc/usr_intf/pncconf folder.
He wants to use the original data from the configs/sim/gmoccapy folder.
The advantage is that there will be no unnecessary duplicate data in the source files.

The problem is that I don't know how to define this path cleanly: configs/sim/gmoccapy
This path is different for RIP installation and different for package installation.

I can define the path for the RIP installation. It is not problem for me.

For package installation I could use the path:
/usr/share/doc/linuxcnc/examples/sample-configs/sim/gmoccapy/
I don't know if this is a clean solution.

I think a clean solution would be to use this variable:
github.com/LinuxCNC/linuxcnc/blob/1c72d4...ipts/linuxcnc.in#L53
But I don't know how.



 

That's a LinuxCNC error perhaps in the modbus code
 
After that error that  you may need to run

halrun -U

or if that does not work, reboot the computer

Because LinuxCNC blocks access to the Ethernet port the 7I96 uses
Until it exits cleanly (this is likely why mesaflash does not work)

After updating linuxcnc, I now get the following:Then I tried:Is the 7i96 toast, hostmot broken? All I did after a few weeks on non use was update llinuxcnc (2.10.0-pre0) I had to compile from source since buildbot is no longer working.
Jim

Like I said before, log in via SSH, wifi it would have to be, run Linuxcnc as you would and if things lock up and SSH is still good start with dmesg then looking through logs.
Also it would be interesting to know if this happens when using axis.
A lot of the investigation will have to be done by yourself.
Obviously it's not a complete machine lockup, as you reported your pendant can still be used to move the machine, so Linuxcnc is able to receive and transmit to your mesa card.
What happens when the machine is left idle without a Linuxcnc session running ?
If are unable, unwilling to address the queries in this post and my previous post I'm afraid I can't offer any help.

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.