Advanced Search

You have

setp hm2_[MESA](BOARD).0.encoder.00.filter 0

(on all axis) You might try:

setp hm2_[MESA](BOARD).0.encoder.00.filter 1

In case it's a noise issue.

Yeah, sorry, I copied them from a 7I96S halshow and forgot to delete the "s"

Thank you very much, I will try those fixes and get back to you.

I also wanted to mention that when we manufacture this machine with new pc hardware and this new software we get the latency warnings but the machine performs without issues. I don't know if that is relevant or not.

Fixed the outputs and inverts for 7i95t, 7i96, 7i96s, 7i97 and 7i97t.

JT

Yes, that is the BOB with very slow optos, and as long as you get latency warnings, the steps might and will be missed, so
-Set the base period to 100000
-set the drive microstepping to 1600
-set the parport reset time to 10000 in the hal file
-set the step time and space to 10000 in the ini
If you still get latency warnings, in BIOS:
-disable hyperthreading
-disable TPM
-disable "aggressive PCI-E power something or another"
-disable any power saving option, like C states, turbo, speed step, etc

The drift might be something physically slipping. Mark any shaft-to-pulley or coupler joints to be sure.
Hopefully it isn't the encoder slipping on the motor shaft, that would be very difficult to detect or fix.

It is unlikely to be lost steps in a closed-loop system, and also unlikely to be lost encoder counts, but it's not entirely impossible.

I don't know why there is a 22.2222 factor on your rotary axes, it feels like that constant factor could be in the INI scaling.

In fact your userkins appears to basically be a trivial kinematics? Why not use trivkins?

Maybe you are running a run-in-place system, so LinuxCNC is running from linuxcnc-dev but halcompile is placing the compiled kins in the root structure?
(But that wouldn't explain why edirting the C and recompiling works...)

I think you are being confused by an old version of 'userkins.c'. Note that

will not create a 'userkins.c' file at all, it will directly create a 'userkins.so' and copy that to the appropriate folder.

linuxcnc.org/docs/html/man/man1/halcompile.1.html

If things are working after
'sudo halcompile --install userkins.comp'
then you can delete the 'userkins.c' file.

You can certainly do this with standard LinuxCNC, so I see no reason that it wouldn't work with PB.

You basically just switch the axis to joint names round. (and, in fact, in many cases you may not even need to do that)

For my horizontal mill I think I used my standard horizontal confic, where table in-out is Z and left-right is X (and I just jogged Y to set tool height)

Hi Tommy.

I implemented the changes you suggested except for those done on the Bios as I do not have access to it over AnyDesk.
After implementing the machine would home correctly as normal, but when running to a set distance the arm would halt after moving about 20 mm and give an error, "joint 0 following error" and this process of moving slightly and giving error happens every time any distance is entered. I also received latency warnings for 100000. I have attached a picture of the errors.

I reverted the settings back one by one and machine ran as it did before only after all changes were reverted. These were the changes I made:

• Base_Period = 100000 >>> set back to 500
• Drive microstepping = 1600 >>> set back to 2000 pul/rev 
• Parport reset time = 10000 >>> set back to 500
• I added STEP_SPACE and STEP_TIME to the "EMCMOT" section as I did not already have it in the ini file. STEP_SPACE & STEP_TIME = 0.00001 >>> I removed these two settings after.

Any thoughts on how to proceed? Thank you for your input so far.
 

mikereid0817 wrote:

Hi Andy... I am muddling my way through this and have things working really well, except inputs. Gpio reads gpio13 fine in python, hal_gpio always shows high in hal scope, meter etc. Any ideas? Is there a way to set gpio characteristics with hal?
 

You can try setting the various modifiers for GPIO13 and see if that helps.
opendrain
opensource
biasdisable
pulldown
pullup
As described in linuxcnc.org/docs/devel/html/drivers/hal_gpio.html#_usage

I am not clear if you are saying that it is always set and the input can not be changed, even if pulled low?

Have you checked with gpioinfo that nothing is claiming the pin?
 

PCW wrote:

No outputs are GPIO

7I96 isolated output hal pins are:

hm2_7i96s.0.ssr.00.out-00
hm2_7i96s.0.ssr.00.out-01
hm2_7i96s.0.ssr.00.out-02
hm2_7i96s.0.ssr.00.out-03
hm2_7i96s.0.ssr.00.out-04
hm2_7i96s.0.ssr.00.out-05

 

Those are 7i96s output pins...

These are 7i96 output pins
     7  bit   IN          FALSE  hm2_7i96.0.ssr.00.out-00
     7  bit   IN          FALSE  hm2_7i96.0.ssr.00.out-01
     7  bit   IN          FALSE  hm2_7i96.0.ssr.00.out-02
     7  bit   IN          FALSE  hm2_7i96.0.ssr.00.out-03
     7  bit   IN          FALSE  hm2_7i96.0.ssr.00.out-04
     7  bit   IN          FALSE  hm2_7i96.0.ssr.00.out-05
and up the 7i96 outputs are using the wrong pins in MesaCT.

I'll fix that.
JT

Do you get latency warnings?
What microstepping is the drive set to?
What DB25 BOB? Some of these have very slow optocouplers, see bellow,
Base_period should be increased when latency warnings appear or when BOB is to slow coupled with to much microstepping set on the drives. Try 100000 at least, even 300000 until you are sure that is not the issue.
Also, step time and step space should be at least 5000, preferably 15000 until this is resolved, then you can try lowering them and the base period while testing for lost steps.

I tuned the FF1 further. Now it looks better. Thank you.

But i am facing a different issue, on all axes, For X axis, i set a dial indicator at zero position and i started 25 full jog cycles for the total distance of 500 mm. For each cycle when the bed returns to the zero position, dial indicator displays a gradual drift away from zero position. Also after stopping the cycles, at rest the bed moves towards the zero position gradually. What could be causing this issue ? Please help me on this

Drift towards zero position at rest is not reflected in encoder and DRO.

Good Day all,
I hope I selected the correct category.

We have a simple 1 axis machine with 2 limit switches. The axis is a ball screw that moves an arm up and down according to user input. The machine's computer runs on Linuxcnc with our own front end software. The linux software is Debian 12. The motor is driven by a Wantai DQ860HA drive and the drive is controlled by a DB25-1205 breakout board.

We recently upgraded the machine to the latest linuxcnc and debian 12 from a previous linuxcnc and ubuntu install. The machine is about 8 to 10 years old with the original motherboard and processor that was installed when the machine was manufactured. 

Since the software upgrade, every 4 or 5th movement is short by 1-2mm. This shortness is not temporary and the machine stays out of calibration(every movement after is short by the same amount) until the machine is recalibrated through the software. The machine will then operate as normal until it gets the fault again and needs to be re-calibrated.

We have added more noise reduction such as running limits through a relay module and adding a better cable with ferrite cores to the step and direction signals as we initially thought it was a noise issue. We have also tried lowering the BASE_PERIOD and the machine's feed speeds and velocities as we thought there might be a timing miscommunication between the new software and old hardware.

None of this has removed the fault and we are at a loss as what to try next.

Any help or recommendations will be greatly appreciated, should you need more information please let me know.