Advanced Search

Thanks for the thanks RotarySMP.
I watch your videos. There's a certain satisfaction in solving the puzzle to bring these machines back to life.
I owe a special Thanks to PCW,  tommylight and others. Without this forum it would have been pointless.

Valve Body Video

Greetings everyone.
So I tested Grandixximo's latest fix.
Slave 0, i.e., the VIPA's I/O, wasn't synchronizing, while the drives were. That is, the VIPA card's Run LED wasn't staying on, but blinking.
So I decided to change the slave sequence. The drives were on 0-1-2, and I/O was on 3, last.
Now slave 3, i.e., I/O, is running correctly.
I started testing. I have the impression that the drive quotas are read faster at startup, sometimes almost as fast as Debian 10. I tried refClockSyncCycles=1 and refClockSyncCycles=-1. In the refClockSyncCycles=1 mode, the axes emit noise more frequently.
The refClockSyncCycles=-1 mode seems to work better, but sometimes I hear a little noise, especially if I move the browser windows.
In refClockSyncCycles=-1 mode, the pll-err pin oscillates from about 800 to -1000, but if I move the windows, it sometimes reaches -10000, and I seem to understand that as the value increases, the noise increases. The pll-out pin stays at values ​​from 2 to -2.
In refClockSyncCycles=1 mode, the pll-err pin always remains zero. The pll-out pin always remains zero.

In both modes, the ethercat command upload -p 0 -t uint16 0x1C32 0x01 returns 0x0002 2, on all axes, including the slave.

I tried changing the sync0Shift value to 500000 without any change.

At this point I'm thinking of changing the PC, I don't want the problem now to be the jitter of Debian Trixie, which is greater, at least double compared to Debian 10.

I'd like to point out that with this latest fix from Grandixximo, the pull-err value is hovering around zero, like Debian 10. While in previous versions the pull-err value was around 99200.
Furthermore, with the latest fix, the plug-out pin has a fluctuating value close to zero, while with previous versions it was always zero.

bonjour , 
je viens de passer de linux 2.5.4 de ma mortaiseuse a 2.9.5, le probleme, est que les signaus de spinbox ne passe plus .j 'ai lu qu il y avais un changement de pyton , j 'ai essayer plusieurs piset et changer post-gui halfile , mais rien ne chan,ge , pouvez vous m 'aider ?
 

usual sim config would be '/configs/sim/axis/vismach/5axis/bridgemill/5axis.ini'

There is also a sim config in 2.10 with newer kinematics that additionally implements 'Tilted Work Plane':
github.com/LinuxCNC/linuxcnc/tree/master...ndle-rotary-nutating

Here is the .ini file for my Gantry.
I think this should help you as a template.

Easiest way would be to add a breakout board like a 7I78, 7I85S, or the common Chinese (Sainsmart)
parallel port breakout. There is 7I96S firmware for all of these breakout boards.

You can use a switch to run up to 4 Mesa Ethernet cards at once, This is better with  hal changes so that
the read times are overlapped instead of added.

Normal hal addf layout would be something like:

addf read0
addr read1
[ bunch of processing addfs]
addf write0
addf write1

But this means that the second read needs to wait for the first to complete before
starting, so to overlap the reads, you:

addf read-request0
addf read-request1
addf read0
addr read1
[ bunch of processing addfs]
addf write0
addf write1

 

 

Yes, I've tried both, neither surfaced the gvcp panel with gmoccapy.

YangYang found something to do OP real quick, maybe will have update tomorrow.

Hi bmoo, have you made any headway wiring your spindle?

It clearly states under point 6 that after switching to the battery encoder cable, a reference run must be performed again. After that, you can comment out the lines.
The internal CIA402homecomp should be used for this one-time reference run.

What do your configurations look like?

I have tried both. Setiing it as an XYYZ and as XYZY. copied joint_1 to the end of the ini and named it joint_3, for the XYZY. for the XYYZ i copied Joint_1 and pasted it between Joint_1 and Joint_2. renamed it as Joint_2 and renamed the original Joint_2 to Joint_3. both times with the same error with the limits of A Axis. when i delete the last joint it starts up as normal.

papagno-source wrote:

Good morning everyone. I would like to do more. I can make an image of my HD and put the image somewhere, made with Clonezilla or other software. Luca, I will contact you, so you can give me a link to support the image. While you have Debian 13, so you can try it on your system. In the meantime, today I will try your patch and try to scale the I/O peripheral, the last one on the bus, and if it still doesn't work, I will change PC.

I don't think that would help much without your slave  hardware. Its not just a simple config problem. The remote access is probably the best way.

You might be better making it a XYZY machine, then just copy down an extra joint in  the ini file and copying the joint setup in the hal file to a new joint 3 section which I basically a copy of your existing Y joint (joint 1 ?) Dont forget negative home sequences for your 2 Y joints.

Alternatively, I set up a new XYYZ machine in pncconf/stepconf very roughly ignore scaling etc, then cut and paste the accurate data you have to the right spots.
Anyway that's how I'd do it. I think the first option is probably easier.

I still use only one servo drive, set the position scaling, the maximum velocity of the system and I am experimenting with the homing.
Now I follow you guide about absolute encoders. I uncommented the rows for homing in the .ini and .hal files and added the missing PDOs for homing the .xml file.
By the way in your .ini file you have a homing settings that are not commented and below them you have commented home settings that are said to be only for homing. But if I uncomment them there will be duplicated home settings. Therefore I commented the first batch with home settings and ran LinuxCNC but the missing pins error appeared.