Advanced Search

Thanks again for your help.  Almost there but a few glitches. The 4th Axis program opens; X,Y and Z axis move however Y will not home. A axis homes but shuts the program down when attempting to move it.  Some type of (following error)..
I added a hash tag to the 3 axis enable line as I was getting an error saying the pin was already attached to another signal. When I applied the hash tag the program opened up.

Would greatly appreciate your comments.  I'm sure you would see the errors much sooner than I would.  It's been quite a learning curve, something I knew I would have to do sooner or later.

thanks in advance

The topic was not updated for a long time. I was trying to get the servo drives work with LinuxCNC and at one point I decided to start from scratch. Now my configuration is with only one servo drive. I managed to get the homing on index pulse working to a certain extent. The problem is when the servo is far from the index pulse, LinuxCNC gives "joint 0 following error". The servo keeps moving but LinuxCNC is disabled. For a successful homing, the motor should close to the index pulse. What is causing the following error? I attached the configuration files. By the way, the homing components used is the standard "homemod".

The "sudo dmesg" command shows warnings about datagram unmatched, time out and slave sync. The tried writing to 1C12:001 and 1C13:001 from the command line but it returns an unknown error "SDO transfer aborted with code 0x06010003". Using the attaced .xml file, when reading 1C12:001 and 1C13:001 from command line, it returns that the PDO mapping is flexible.

Can you make a new very simple config and test again?

Very weird symptoms...

Probably should be returned for evaluation

As last check on the software side, can you post you hal/ini files?

I rather suspected that was the correct way to do it. I'll work on it.

thanks for you help.

github.com/LinuxCNC/linuxcnc/actions/runs/24246961815?pr=3807

new build has slight speed improvement, still working on it

I've never experienced the lag/delay you described. My setup seems to respond instantly to the pendant.

I guess I'll give the ferrites a shot.

I know TP2 does not support G33.1 yet, I thought TP1 did but never tested, might have to do some work there, thanks for reporting, will try to patch it up soon

I measured again

from +5V to DIR+ = 5.13V and drops to exactly 5V when jogging in the negative direction


from +5V to DIR- is always at 0V That's for all channels on TB2 1, 2 and 3

Do you think i got a faulty board, Sorry this is getting so frustrating

The signals are differential but can be used single ended
That is DIR+ and DIR- should both change voltage when
the direction changes but one should change from 0 to 5V and the
other from 5V to 0 (relative to ground)

Measured differentially, you should always measure either
+5V or -5V across the DIR+,DIR- or STEP+,STEP- pins.

spumco wrote:

I consider any of the Mesa SmartSerial boards to be 'direct I/O' as that method of connection is rock-solid and there's no human-perceptible lag or latency.  Which means a hand-held MPG with a 7i73 inside (for the digital display) will be be just as responsive as the panel-mounted stuff I built.

Well there are wireless pendants that wire into direct I/O (but they are not USB) that will give equivalent response
www.wixhctech.com/product/23.html
They use a lot of I/O but you can get versions that use digital inputs (which I have used) that save a few inputs
 

Yeah i checked it in halshow under parameters
step_type is 0

devils4ever wrote:

Thanks for your input. That makes sense. Is it worth trying some ferrites?

Are there other brands/models that are more reliable and easy to configure with LinuxCNC?
 

Clip-on ferrites are cheap on Amazon if you want to try it.

Is it worth trying?  Up to you.  I got fed up with the iMach even when it was working.  Because it uses USB - and possibly because of how it's programmed - there is a delay between when you stop moving the wheel and when the machine stops.  If you move the wheel fast back and forth, you can get to the point where the machine is moving opposite to the wheel direction.  Totally unsafe.

I got used to industrial machines with "direct" I/O MPG's and control buttons.  On those machines, there is zero perceptible delay between control input and machine response - even to the point where big machines will jump and jerk trying to keep up with aggressive commands.  Having experienced that, it's like the difference between driving an F1 car and a 1970's Oldmobile with worn-out suspension, spongy brakes, and a sloppy throttle cable.

My personal preference is a standard A/B quadrature encoder, connected directly to Mesa inputs. All critical controls (cyc start/stop feed hold, RRO/FRO/SRO, continuous jog buttons, etc) are also direct inputs.  No microprocessor, no cool features, no wireless/wifi.

I consider any of the Mesa SmartSerial boards to be 'direct I/O' as that method of connection is rock-solid and there's no human-perceptible lag or latency.  Which means a hand-held MPG with a 7i73 inside (for the digital display) will be be just as responsive as the panel-mounted stuff I built.

I have no experience with ethercat (native ethercat device or using a drive's I/O as GPIO), or any of the countless other clever methods folks have devised to expand IO by offloading through a USB or other bus of some sort.

Just take you XYYZ config and modify it by adding an extra joint and XYYZA
At this stage, you need to leave pncconfig or stepconf behind and work directly with your hal and ini

manpages.debian.org/unstable/xinput-cali...calibrator.1.en.html