Advanced Search

tommylight wrote:

How much is that in distance?
 

Tommy...
The standard encoder for Clearpath is 800 counts/rev.  With 4mm pitch screws that's about +/- 20 microns before the servo vomits.

OP...
I've had issues with clearpath step/dir that were resolved using the resistor they indicate in the user manual.  Your cables may not be very long (mine were ~20 feet), but it did help with lost pulses from the PLC to the motor.

Note that I never had an issue with direction changes, only the motors not moving as far as I'd expected.  I chased couplings, planetary reducer shaft clamps, and everything mechanical until I put the resistors in.

Also, Clearpath has an input filtering setting in MSP software; might want to play with that if you think some of the pulses are going astray.

 


 

It actually happened again last night. Off of a fresh start of Probe Basic, I probed the tool with the tool setter and hit Go to Zero and got the errors. I wasn't able to replicate it again though after clearing the G54 offsets that were previously stored. It's hard to remember what caused the issue when it happens unexpectedly. I'm sure I'm missing something.

Yes, Tormach Is part of ETG as well.
Are you using my repo's code or sittner's?
The random OP cycling is gone?

rodw wrote:

To use Ethercat, you need to become a member of The Ethercat Technology Group (ETG). Membership is free. www.ethercat.org/default.htm
But membership is only open to companies or businesses and you need a tax number or equivalent in your country.

Linuxcnc is nothing, just a loose community of users. We don't even have a bank account.

This has been explored by a number of the development team members over the years. Most recently by Steffen Moller who lives in Germany where the ETG and Beckhoff are domiciled. (I may have prodded him in this direction)
I had the opportunity to raise Linuxcnc with Martin Rosten, Chaiman of the ETG when he visited Australia a few years ago. There is no way forward.

But now etherlab have a repository and also host the linuxcnc-ethercat driver and I put that repository into the Linuxcnc installer, there isn't really any need for linuxcnc to get involved. (Except to manage the code base).

I would recommend you and Grandixximo as manufacturers join the ETG.

Ok, so my inevitable follow up, what is tormach doing? Is it different cause they supply it in an installed state - installer method is irrelevant? OR are they as a company a member of ETG?

I don't currently supply any actual electrical directly. I just point people to linuxcnc for now. We are likely going to try and maintain some sort of guide with our config files to set things up, which will include this new patch. To make things easy and consistent for people.

Oh, and thanks everyone involved for this fix. It really seems to have solve quite a lot of little gremlins in one go.


 

I would also try:

1. Single ended step/dir wiring:

7I96S +5V --> MOTOR STEP+
7I96S STEP- --> MOTOR STEP-
7I96S +5V --> MOTOR DIR+
7I96S STEP- --> MOTOR DIR-

2. Increase the step length (double if possible)

Already replied in the French section.

forum.linuxcnc.org/10-advanced-configura...ning-detailed-how-to

maruf1777 wrote:

HLFB is configured at 20 counts and did NOT trigger.

How much is that in distance?
And that goes both directions, so the actual error can hypothetically be 39 counts without triggering.
Granted, i agree with others, interference is the first thing t eliminate as you do have cumulative errors on both axis, and probably the third, too.

 Not sure if you have a cut chart for that machine.  Have a look at this generic cut chart to get a sense of amps to use for a thickness. It will also give you a guide on speeds.  1.5mm cut height and 2.5 to 3mm pierce is pretty standard.  

 


 

It is. I just bought some MR-J3-70B drives, for 29$ per drive, so I guess I'll have to get one of your cards next. Do you have an ethernet driven version? Or just the PCI version?

I hooked up one of the -A copper drives today in step/direction mode, and honestly it isn't that bad to hook up and it worked perfectly, but if I go with the SSCNET system, I can implement more drives without having to add more cables, just extending the fibre interface.

Eventually I'd like to have the tool changer on the SSCNET link as well, and that would be another 200W servo or two.

You can zip the program and attach it to the original post here.
Or make a new post as the editor likes to mess formatting.

I have written a pocketing program using g-codes, it pockets triangles, rectangles, trapezoids and some unusual shapes. the attachment has a screendump of eight different ones.  The program is available as a .ngc file and runs on linuxcnc/axis version 2.6.13 on ubuntu 12.04 LTS 32 bit (using the rtai kernel to operate a Taigtool mill through a xylotec controller.)  I would like to donate this program to the site if there's any interest)  my email address is This email address is being protected from spambots. You need JavaScript enabled to view it.  
the program  is 580 lines long and includes 112 lines of sample polygons. it uses "o" codes a lot.

none. forget the rs422.
ok, you probably can read something out of it with a userspace comp with a limited frequency.. e.g. a torque feedback comes to mind. but i can't imagine anything else. doesn't worth the trouble, imho,

you'll need at least servo-on, step, direction outputs wired to CN1. alarm input is a must. utilizing absolute encoders require 2 more inputs and 3 outputs...

sscnet is so much more convenient...

Hi...Have a diy cnc Wood lathe...have rough/finishing tools mirrored on part doing frequent arcs.....so one axis,2 tools..was hoping to put them on same side with 1" between them...in order to cut the same path finish tool would have to be delayed, then follow on toolpath..is this possible with joints?..
Also would need to use a different diameter offset for finish tool as it will need sharpening more often than rough...possible?

Thanks for any help,

Rick

maruf1777 wrote:

DRO shows identical position at arc entry and exit — LinuxCNC believes the machine returned to the correct point. But probing a fixed reference shows X shifted +9.3mm and Y shifted -12.2mm. HLFB is configured at 20 counts and did NOT trigger. This means every commanded step was executed by the motor. The error is in the arc interpolation — the step path LinuxCNC generates to trace the circular arcs does not sum back to the correct physical position.
LinuxCNC version: Master (2.9), running on Raspberry Pi 5 (4GB), Debian Bookworm, Mesa 7i96s over ethernet (hm2_eth), SERVO_PERIOD = 1000000.
 

Linuxcnc doesn't generate a step signal. All planner calculations are based on position (float64 number) and velocity signals.These numbers (not steps or pulses) for each servo cycle are sent to the Mesa board, where "stepgens" converts them into pulses.

These are the connections in hal:
joint.N.pos-cmd -> hm2.N.stepgen.position-cmd;

Each cycle, Mesa sends back the counted number of generated pulses for reporting:
joint.N.pos-fb <- hm2.N.stepgen.position-fb;

The difference between the sent position and the feedback is tracked using the joint.N.f-error pin.The path planner (on the computer) and stepgen (inside the Mesa board) do not influence each other, but each performs its own role in the chain.

I hope you understand that, in this logic, the position can't simply shift in the planner. If there was an error, it would mean it was transmitting an incorrect coordinate to the mesa, and the same incorrect coordinate would be visible in your DRO (since it's also connected to the joint.N.pos-cmd == axis.N.pos-cmd signal). And the incorrect path would be drawn in the graphics window. The "live plot" draws either based on the pos-cmd or pos-fb numbers. there's a switch for this.

If "LinuxCNC believes the machine has returned to the correct point," then the planner has indeed returned to that point and is transmitting that exact position command to mesa.If the error occurred in stepgen inside mesa, then the position-fb counter would have returned an incorrect number of counts (as a float64 number, not pulses).

If your servos don't report their own following error, then there remains the possibility of an error between Mesa => Servo. Due to electrical interference/noise, not all pulses could have been received by your servo - it thinks it's following the path, but in fact, not all the pulses reached it.
This is confirmed by the fact that you saw a connection between the error and pulse timings.

I have been working with linuxcnc and fusion 360 for a long time as post programmer, so I can assure you - there is no connection between the post processor, pathplanner and your problem. Both work fine.