Advanced Search

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?

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.

The STEP/DIR output voltage will be the 7I96 5V supply voltage
if there is no load. Any load will lower the output voltage.
So it could be low supply voltage, or a load on the output
The output resistance is around 50 Ohms so a 10 mA load will drop
the output voltage by about 0.5V

ahhh thanks pete!  i just came across that just a few minutes ago. i thought that looked suspect. must be a bug in jt’s config tool because thats straight out of mesaCT. 

quick question, any reason i cant get more than 4.45v out of my pwm?  ive checked everything on the hardware side and its all good there. no matter what i do, i cant get more than 4.45v max from the pwm

Dont merge anything just yet. me and my friend have spent the last 3 days trying to figure out the shit outta this problem. we have environment configured, we can switch uart, but we are very stuck and out of ideas. We are trying to switch SPI channels from 1 to 2 and/or 4, but we just dont know what variable we are missing/not configured. It works mostly but the MOSI doesnt seem to work but the MISO does. SPI1 works fine, but we cant figure out how to switch to 2

github.com/cakeslob/Remora-STM32H7xx-PIO/tree/h723
github.com/cakeslob/Remora-STM32H7xx-PIO/tree/spi4