Advanced Search

langdons wrote:

LinuxCNC should have some auto config option where you just let it run and it figures out where the home switchs are and everything.

To be able to do that for any of the huge variety of machines that LinuxCNC can control, it would require the software to be SENTIENT!!!
Nothing humanity can create can do that the way you think.
Try AI
-
Off topic:
AI = absolutely not artificial intelligence, not in the slightest, just the name being misused.
Same with:
Calling a liquid "GAS"
Calling "football" a sport that does not use feet.
Etc, etc.

Thanks, So in Z with scale being positive. Z moves by pressing the - jog moves towards spindle (+) jog moves away from spindle. (Which is correct) Search Vel is 15(+) but still searches left(-) towards the spindle. If I but ser Vel to negotiate it searches away from the spindle.

If I set Z scale to negative . The motor is reversed and when I press jog (-) it  moves away from the spindle.(Reversed)

It seems the machine is working correctly the way it's set. It's when I load a program it's all reversed 

Edit 
I just set the Z offset 150 away from the spindle .but ser Vel had to be a negative value for it to move away from the spindle. Even though my z axis is moving correct when pressing the - and + jog

Yes. It looks the same with my 4 axis machines. Normal tp works with different machine setups without a problem. The scurve tp jumps all over the place! But. Only if a fourth axis (rotary, A) is involved. 3 axis programms without a problem.

Looks also that the axis gui is not really "connected". Preview an tp are working without connection.

Why are you still whinging ?

The settings are in the ini and hal files

Just post them

Another important issue is the jerk and acceleration at the segment junction. 
 
 
 

The coordinated velocity and acceleration values on the TP pins look correct. But the values for each axis individually have instantaneous velocity changes (0xVel to 2xVel) at the segment junction, and acceleration jerks that exceed the limits (over 100K). This looks like a calculation error.

On a polyline path it makes a jolt with a frequency of 10-100ms. 
With this speed signal, the servos and PIDs go crazy and can't work.



And the last less important problem I saw is that on a non-realtime system TPMOD stops working when trying to load a programme larger than ~100-200 lines. Therefore, simulation and testing have to be performed only on a realtime system

I would like to express my gratitude. Thank you very much Grotius for doing a great job despite some problems that can be solved. The linuxcnc tp has been in need of improvement for a long time. 
I can provide all the programs I used for the comparison, maybe it will help to fix the errors.

juliankoenig87 wrote:

 I always set with a P value the maximum allowed deviation of a given path. So now I am not really sure. Can I just calculate something?     
 

Yes. Such smoothing is not optimal. The value of P should certainly be the limit of deviation from the programmed path.

I am also concerned about the compression algorithm that creates polygons if you increase the ‘P’ value. I have prepared a comparison with the old path planner:
 
 

It shows that first the polyline is compressed by an algorithm similar to Douglas-Peucker, then the large lines are connected by a b-spline whose radius of curvature is limited by acceleration.  This creates constant changes in velocity, acceleration and deceleration that are bad for milling. The most important thing for milling is to maintain a stable speed. The optimum solution would be to drive with minimum curvature over the entire trajectory. The last image shows the difference in 3D milling.
 
 

The old planner produces a path with minimal curvature, but it always tends to move inside the curve. A similar effect can be seen in this animation comparing "Moving Average" and "CCMA": 
github.com/UniBwTAS/ccma/raw/master/figures/demo.gif


I also have a problem when the trajectory is plotted with a lot of smoothing errors - it randomly moves far outside the limits:


I can provide all the programs I used for the comparison, maybe it will help to fix the errors. 

LinuxCNC should have some auto config option where you just let it run and it figures out where the home switchs are and everything.

Then, all you would have to do is tweak it so the distances are correct.

In Stepconf, I see a home switch location setting, but no home switch direction setting.

Aren't they sorta the same?

After all, if you know where something is, you know which direction to go to get there.

blazini36 wrote:

The file browser is a little hard to navigate because it doesn't show the current directory, easy to get lost. Any chance you can add current directory at the top or something?
 

Do you have an example of what you mean? I'm having a hard time visualizing that...

JT

To change the jumper position just pull the little link off and put it back on the top pin

Murphy wrote:

The one labeled Remora 
 

I just edited my last post after having a think.  Ignore the STEP_SCALE value from the wrong INI... but apply the concept and put a minus sign in front of your existing value.

The one labeled Remora 

blazini36 wrote:

Didn't get a chance to update and try the label yet as I'm working on the hal file at the moment. Couple of things I'm noticing now that I'm running some sims......

Since I added a qss, INPUT = TOUCH seems to not have an effect anymore. Pretty sure I had the touch style file browser before the qss but now it is back to the normal one.

The file browser is a little hard to navigate because it doesn't show the current directory, easy to get lost. Any chance you can add current directory at the top or something?

The flood and mist push buttons disable when a program is running. I'm used to Gmoccapy where you can still operate the mist and flood while running a program. Sometimes I forget to add coolant to the program and need to turn it on when it's running. Not quite sure why yet but as soon as the GUI disables coolant even if I stop the program I can't control it again with the hal buttons until I first turn it on with the GUI buttons.
 

The ini entry INPUT is now THEME gnipsel.com/linuxcnc/flexgui/ini.html#themes

Which file browser, the keyboard or the touch screen?

Good point on the flood and mist and I see no reason to disable them at any time and that has been fixed.

JT

PCW wrote:

I would not use the 192.xxx.xxx.xxx range, but rather set the 7I96s
to 10.10.10.10 = W4 down W5 up +power cycle and set the host address
to 10.10.10.100:

[
auto eth0
iface eth0 inet static
address 10.10.10.100
hardware-irq-coalesce-rx-usecs 0
]

 

Hi,

Thank you for your reply. I would like to use 10.10.10.10 also: I have read the manual on this part and I have watch some set up vidoes for this card too. But I am not entirely certain about the jumpers. Please refer to the attached image:



To pull W4 down, do I just push that shiny piece pointed to by the green arrow down, please?

Thank you and best regards,

...behai.

rodw wrote:

Please watch my video

start at about 16 minutes in if you want to get to the section on networking
 

Hi,

Thank you very much for your suggestion, I did watch the entire video. I understand your explanation on the TCP/IP protocol.

Best regards,

...behai.

Which of the three INI files is yours?

EDIT - 

The search velocity for home is a positive number. It should be negative? But I change it it goes the wrong way.

Your home/limit switch is to the operator's left (towards spindle) - i.e. Z-negative.

If you edit your INI file so that the initial home search is negative, but the Z-axis moves to the right, this suggests your Z-axis motor direction is backwards.

You can change the Z motor direction in INI by changing the sign of the step scale (to positive):
[JOINT_1]
STEP_SCALE = 50799.998

Try changing the motor direction and set your homing direction as negative and latch velocity as positive:
HOME_SEARCH_VEL = (negative number)
HOME_LATCH_VEL= (positive number)

Once you get this sorted, you may also want to adjust your home offset so that the Z-positions are more like 'normal' CNC lathes.  "Normal" lathes have G53 Z0 at the extreme limit away from the chuck/spindle.  Commanding a 'G53 G0 Z0' will result in the turret/slide moving to the safest position (extreme right end).

If you leave the home position (G53 Z0) near the spindle end you'll have to be very careful about G53 and G28 homing moves since LCNC has no idea what chuck is mounted or what stock is in the chuck.