Advanced Search

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.

Oh thanks! you're right that halcompile is having some problem, userkins.c is unchanged after I run. There's nothing in the terminal that hints at it not working.

Compiling realtime userkins.c
Linking userkins.so
cp userkins.so /usr/lib/linuxcnc/modules/

I've attached the userkins.comp file here

Sounds like a problem compiling the .comp file as the 'halcompile' tool would not add or remove anything in those lines.
Impossible to say without actually seeing your userkins.comp file.

but does it hurt to have it there?

That's a matter of opinion. My opinion is that I don't like it there. I'm very conservative and I don't like a lot of change.

We could also ask ourselves if the display of G-codes (and maybe Tool Information as well) is necessary in manual mode.

For example, this is needed to check whether G43, or G49, or G54 or G55 is active. Next, in manual mode, I check the Z-axis compensation. Some users use multiple compensations for one tool. For example, for T6, they use G43 H106 or G43 H206. Next, the manual mode window is the window that the user will see immediately after selecting a tool in the tooltable.

Could be, but I can't figure out where it's coming from, so looks like I'm stuck with a temporary fix of a possible temporary fix for now.

I remember Python giving me so much grief over the tabs and spaces in my first year of learning to program! At least these days IDEs take care of that problem.

C just went completely over my head when I tried to learn it. I can mostly read it but I cannot write anything in C, it's pretty frustrating

zz912 wrote:

Your answer is a technical explanation of why this is the case. However, I look at it from a user perspective. I take it that there is unnecessary information in manual and MDI mode. I understand that removing this is extra work, but it is not unsolvable.

Sure I can hide it in other modes than auto, but does it hurt to have it there?

We could also ask ourselves if the display of G-codes (and maybe Tool Information as well) is necessary in manual mode.

I think the switching of the visibility would confuse the user more than it would help. At least now as we have enough space.

Was able to build and test it. Interesting.
There is the problem with the size of normal data types.
But also with compound variables/pdos like an uint32 that is really 12 bits input and 20 bits of nothing. Can be handled separately in a hal component to create individual pins I guess, but adds to it.
The naming of the pins is horrible, but you have all the info from the drive so can be fixed.
It's easy to compare to the situation with lcec_conf that offers solutions to I think all situations.
But adds its own complexity and isn't ideal. Too many details often go wrong.
You made a start with the ethercat_twincat configurator, that looks like an appealing way forward.