Advanced Search

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.

For the Linuxcnc Raspberry Pi images just don't do dist-upgrade, it will break things, this has been proven.

You get get away without doing any kind of upgrade.

If you are worried about security, updates are only a small part of the picture. The first step should always be physical security, which should be the number one priority with a computer running a cnc machine.I'd take data loss over damage to a cnc machine any day of the week, you can't back up a cnc machine.

I would still appreciate knowing how to call anyone of these routines without going through the entire program.

You can call any subroutine in a loaded program from MDI (eg 'o100 call')

Also how to set the Z after the tool change.

Do you mean the tool-length offset or the work-offset?

The currently active work offset can be changed like this:
'G10 L20 P0 z123'

What about the "rawcounts"? when i quickly had a look at them in halscope they seemed to have "0" at a fixed location, do you think that's something i could use in some way?

langdons wrote:

Is dist-upgrade ever a good idea?

Yes, when you download an ISO, it might be several months old, so that will update to the latest stuff for that distro, including kernels and stuff that "might break things".

pgf wrote:

p.s. Best tech support ever...

Yes he/it is.