Advanced Search

Something to keep in mind when you think you're going to lose your mind!

I spent a number of hours yesterday working on servo tuning and I wasted time with something I didn't expect.  I kept seeing glitching in my f-error that I couldn't explain.  After checking for mechanical issues (belt slip, loose mounts, etc.), on a whim I happened to try some moves from the MDI - and surprise, no more random glitching!

Long story short, it turns out key repeat was causing problems.  It's easy to 'fix' by issuing an xset -r command to disable key repeat.  There are other approaches as well, a forum search will turn up a few threads.

Here's what I was seeing with key repeat enabled.  You can see the spikes in the velocity command.  It really wreaks havoc on the f-error.
 

And when it's disabled, no more random glitches.  Terrible servo tuning, but no glitches!
 

3 very fast optocouplers would be needed to have full isolation, if you need ABZ signals.
-
If you already have drive and Mesa wired and working, use a DVM to measure the AC and DC voltage between drive encoder gnd and Mesa encoder input GND, any reading above 0.1V means using optos, but if they are under 0.1V it will probably be safe to wire just ABZ signal pins to Mesa.
You have to measure those with drives off and again with all drives on and working as drives cause a lot of EMI.
It would be even better if you have a scope to actually see how much interference is there as the DVM is not very good at that.
Again, do this at your own risk, there are to many variables there to be certain.

Make sure you have this in the [HAL] section of your ini file:
HALUI = halui

Hi @all,
i try to setup a new machine with Linuxcnc 2.9.2
and i have trouble on a Logitech Joystick - some strange Messages
joypad_xz.hal:32: Pin 'halui.machine.is-on' does not exist
11105
11136
joypad_xz.hal:36: Pin 'halui.joint.0.analog' does not exist
10613
10645

something changed in halui?

 

I have a raspberry pi5 and this is the code of how I started the SPI communication of the RPI5 - TangNano9K. (Not yet machine tested)

OS: 

• LinuxCNC 2.9.2  Raspberry Pi 5 OS based on Debian Bookworm  Raspberry Pi 5 Uspace compatible with Mesa Ethernet and SPI interface boards.

In /boot/broadcom/config.txt check is SPI is enabled (reboot if not)

# uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
dtparam=spi=on

In /dev/
Check do you have listed spidev0.0, should be!

In RIO.h define:

#define TRANSPORT_SPI5

In RIO C add lines:

#ifdef TRANSPORT_SPI5
#include <linux/spi/spidev.h>
#include <sys/ioctl.h>
#endif

/***********************************************************************
*                STRUCTURES AND GLOBAL VARIABLES                       *
************************************************************************/

#ifdef TRANSPORT_SPI5
int spifd;
static uint8_t mode = SPI_MODE_0;
static uint8_t bits = 8;
static uint32_t speed = 1500000;
#endif

/***********************************************************************
*                       INIT AND EXIT CODE                             *
************************************************************************/

#ifdef TRANSPORT_SPI5
    rtapi_print("Info: Initialize SPI5 connection\n");
    spifd = open("/dev/spidev0.0", O_RDWR);
    if (spifd < 0) {
        rtapi_print_msg(RTAPI_MSG_ERR,"Failed to open SPI device\n");
        return -1;
    }

    // Set SPI mode
    if (ioctl(spifd, SPI_IOC_WR_MODE, &mode) == -1) {
        rtapi_print_msg(RTAPI_MSG_ERR,"Failed to set SPI mode\n");
        close(spifd);
        return -1;
    }

    // Set bits per word
    if (ioctl(spifd, SPI_IOC_WR_BITS_PER_WORD, &bits) == -1) {
        rtapi_print_msg(RTAPI_MSG_ERR,"Failed to set bits per word\n");
        close(spifd);
        return -1;
    }

    // Set max speed
    if (ioctl(spifd, SPI_IOC_WR_MAX_SPEED_HZ, &speed) == -1) {
        rtapi_print_msg(RTAPI_MSG_ERR,"Failed to set max speed\n");
        close(spifd);
        return -1;
    }
#endif

//Edit rtapi_app_exit function, add close(spifd)

void rtapi_app_exit(void)
{
    close(spifd);
    hal_exit(comp_id);
}

//In fuction void rio_transfer()  near end of it add: 

#ifdef TRANSPORT_SPI5

    struct spi_ioc_transfer tr = {
        //.tx_buf = (uint64_t)tx_buf,
        //.rx_buf = (uint64_t)rx_buf,
        .tx_buf = (uint64_t)txData.txBuffer,
        .rx_buf = (uint64_t)rxData.rxBuffer, 
        .len = SPIBUFSIZE,
        .speed_hz = speed,
        .delay_usecs = 0,
        .bits_per_word = bits,
    };

    // Perform SPI transfer
    if (ioctl(spifd, SPI_IOC_MESSAGE(1), &tr) == -1) {
rtapi_print_msg(RTAPI_MSG_ERR,"Failed to perform SPI transfer\n");
        //close(spifd);
        //return -1;
    }

#endif

//Save and do hallcompile...
 

The simulation configs will not run actual hardware.

jimmyrig wrote:

sometimes when using ohmic touchoff it would hit a pile of junk, bird poop, etc , and ohmic would not sense. This would cause the float switch to trip but it wouldn't continue...... would just get stuck. pause, unpause, stop, restart from line, etc nothing would make it pierce. Would required a full reset of linuxcnc, disabling ohmic, allowing it to pierce, with float, then going back to ohmic mid program. This happened ~25 times. every now and then it would work with the float if ohmic failed but not usually (or maybe i just didn't notice until it failed)

Could you post the zip file created by the BACKUP CONFIG button in the SETTINGS tab. 

z axis, if failed to home (broken stepper wire) would still cause the x and y axis to move even after it failed!!!!!! had this happen twice over the last year with the thin nema 17 wires breaking at the connectors after all those pierces.

Do you mean that X and Y continue moving to home after the failure? 

i have a custom user button to move the table to origon. However their is no way to stop the machine from software after that command has been sent (left parts on the carriage a few times whoops) requiring the estop to be hit, when a simple pause or cancel would have worked great.

Cycle Stop should stop motion, the Esc key should also stop motion if you have keyboard shortcuts enabled. 

Missing Features (hope this is around now)
the biggest one is when the program is paused (cause the tip is burnet out), not being able to move to a specific location to make changing tips easy.

Change Consumables was provided for this.

I am upgrading the table to include a 4th axis rotary and figured i would update the system to debian 12 while at it and provide a update on how things went. 

I forgot to push that update, if it wasnt made will push it when i go to debian 12. 

Well its been a while but here are the results of ~ 1 year of use. (see pic)
a little over 8.4 miles of cutting or 13.4 km, and about ~53k pierces. 
torch was on for 63 hours. 

ohmic has worked flawlessly in all kinda of weather (rain/snow)/ well below freezing to very hot. (table under a carport so kinda exposed to the weather),. I much prefer ohmic as i full rapid for each pierce so times are ~1 sec instead of the ~3-4 that probing takes.....when doing ~53k peirces that saved a day worth of run time!

a few bugs i ran into, not sure if they have been fixed as i am on the same version (been to big of a chicken to update... trying to keep up with orders so didn't want to break things) 
1. sometimes when using ohmic touchoff it would hit a pile of junk, bird poop, etc , and ohmic would not sense. This would cause the float switch to trip but it wouldn't continue...... would just get stuck. pause, unpause, stop, restart from line, etc nothing would make it pierce. Would required a full reset of linuxcnc, disabling ohmic, allowing it to pierce, with float, then going back to ohmic mid program. This happened ~25 times. every now and then it would work with the float if ohmic failed but not usually (or maybe i just didn't notice until it failed) 
2. z axis, if failed to home (broken stepper wire) would still cause the x and y axis to move even after it failed!!!!!! had this happen twice over the last year with the thin nema 17 wires breaking at the connectors after all those pierces. 
3. i have a custom user button to move the table to origon. However their is no way to stop the machine from software after that command has been sent (left parts on the carriage a few times whoops) requiring the estop to be hit, when a simple pause or cancel would have worked great. 


Missing Features (hope this is around now)
the biggest one is when the program is paused (cause the tip is burnet out), not being able to move to a specific location to make changing tips easy. 


Below is my current ohmic setup via a terrible paint drawing if anyone wants to replicate my setup.

5x5k 1w resistors for ~25kohm (22.5k in reality)  between v+ of power supply and in- of thcad.. The table connects to -in at the thcad as well
1x250kohm resistor between thcad v+ of power supply and in+ of thcad
power supply v- to torch (ohmic shield) 

With this setup when the torch is full of junk it reads ~24v letting you know the torch is messed up while allowing ohmic probing to continue
 

I've started a new project, this time a CNC machine. I did a little design review video. I want to try to make a machine with auto tool change. Setting up the ATC will probably be the hardest part of this project for me. So get ready, I will ask nub questions)

PCW,
Nice board. 
I lack some fundamental electrical knowledge. In general, on a line driver type differential encoder, if the receiver is only single ended (my drive), it was my understanding that one can still read in just the A and B channels. If so, do /A and /B need further termination or can they be left floating/unconnected? 
Or is it better to just get a single ended encoder if the receiver is single ended? 

Tommylight,
I have a split setup on a lathe spindle that works very well with rigid tapping / threading and css. I'm reading in differential on both ends one to encoder card on vfd and the other to 7i77 for velocity control, so not trying something odd like current setup.

Current problem is trying to get a 4th axis indexer working. The drive (AMC ab30a200) only reads in single ended encoder for velocity feedback. I'm not sure why a new analog drive would have limited encoder channels in addition there is no encoder out from the drive to linuxcnc.
I think most of the digital drives have the additional encoder output. Unless I'm missing something, I'm forced to split it if I want encoder feedback.
One option is I can use current mode in the drive and read in the encoder on 7i77 only. Unfortunately  I can't get good shaft lock in current mode.
Best option so far is hall velocity feedback in the drive and encoder to 7i77. Shaft lock is good but runs somewhat rough. Suspecting noise and bad encoder signals. This drive is not isolated. That was an extra option.



 

I am using 2.7.  Its coming back together after being in storage for years.  I have no intention to upgrade for awhile.  I want to know , should the machine respond to the computer running the sample program?  In AXIS, the machine responds to me giving it directions.  But not when i tell it to run that "Linuxcnc" program.  The sim runs.  But machine does not.

Well you can do alot of things, doesn't mean it's always a good idea. Somebody just posted about those CUI encoders that according to the datasheet don't even drive enough current to operate the receivers on a Mesa card according it it's manual.....maybe it'll work, probably not a good idea. When you start having problems you have to ask "what are the things I did that were not good idea?" If it just works, why bother asking?

I have no idea what kinda drives or encoders we're even talking about here, just making suggestions specific to the questions that were asked.

andypugh wrote:

I have occasionally wondered the same thing.

There are Mesa card UARTs that can be used in realtime, but I have not seen anyone use the built-in serial. Mostly folk seem to use USB to Serial dongles for (non realtime) Modbus etc,

If you want to experiment, perhaps the mesa_modbus driver code could be modified to work with the onboard serial?
 

Was actually hoping you'd reply, judging by your response it sounds plausible.

Mesa UART via the RS422 connector was the first thought but that kinda lead me down the path of "why can't I just do this with a native serial port?" Pretty much any miniPC or even an RPI will have UART pins, it's a pretty simple electrical conversion to get RS422/RS232 or even RS485 out of that, I suppose it's easier to just plug in a USB dongle but in my experience the electrical part of dealing with serial stuff has never been the hard part.

The components named "modbus" I've never really looked at as I never really use anything that supports modbus. I was looking at the modbus protocol and I'm curious if they could be used with a standard DMM servo drive. There is a modbus version of the drive but the only thing I really know that's different is it uses RS485 rather than UART. The data structure looks really similar.

forum.linuxcnc.org/show-your-stuff/47357...ines?start=10#257711
Accidentally had a look there and sure enough right at the end of the video you can see the Z axis motor with the added encoder, but not much help, dark, far away, etc and the youtube recommendations plastered all over...

I am using split encoders on a plasma machine, with no isolation and no add on boards, but that implies having both sides at the same potential, failure to have them at the same potential will end up badly.
Do not take this as advice to do so, just as a "can be done" thing.
forum.linuxcnc.org/show-your-stuff/47357...ines?start=10#257711