Advanced Search

yes! built with canbus. saves a lot of cables and is easy to implement.

For time like this, I generally make a now config  with pncconf with some rough settings. Once you see movement, then cut and paste stepper settings and pins from your old config.

>Halshow has the reading fluctuating from about -3650 -> +3650 with no plasma source having power.
you have a 0 volt frequency of 3637 in you system so 3650 is expected. The swings are not
There is something not right in hal, like you have a double ended encoder or something.

my1987toyota wrote:

There is rumor of Big Tree Tech making one, but that is still just a rumor.

Thats the one!
biqu.equipment/products/bigtreetech-pand...fP0vAWLH50KrWga94hgp

tommylight is this just more of the test?

If you don't want to stick to Ethercat drives for all axes, really you should not have gone down the Ethercat route. Rtelligent and others have closed loop Ethercat stepper drivers. I would get a couple of them. Leadshine and Rtelligent also have open loop drives that control 2 x steppers in a single drive.

Rtelligent and Deiwu both have more affordable Ethercat I/O options

Thanks for the answer but I wasn't referring to how to use and2, hahaha.

I was referring to the limit3 component when the limit3.enable hal pin is set to false the output goes to zero, in case of connecting the and2 output to the limit3 enable if you write a measurement to the limit3.in hal pin and press the buttons you may need to release the buttons during the movement, at that moment I need it to stop as quickly as possible but not to go back to zero, or better yet you can press the buttons and reach the measurement and then when you release them you go back to zero, hahaha.
It may be that some applications require going back to zero but not all, imagine a measuring stop on a saw, or a double head miter saw, no interpolation in this case it is necessary that when you give a measurement you move the joint to go to the measurement and stay there or if you release the buttons in the middle of the movement it stops and when you press them again the movement resumes, this is what I am referring to.

I have now achieved this behavior, I have had to make changes in the limit3 component, in how the enable is interpreted with respect to the measurement, later I will upload the modified component in case anyone wants to take a look.

As always, greetings and thanks to everyone.

The DM556 will be fine at 57 volts AC
I have drivers rated or 65v AC and have run them at 64V and had to pay attention to other parameters as that was so close to the max.
So next time I ran them at 60v AC and then finally found the manufacturers specs which I think said 55 volts was recommended!

As far as DM556 goes, 40 volts is probably OK too. It is possible to calculate the maximum voltage to achieve specific performance. A friend developed a spreadsheet that does this. In a recent design for  2 amp Sanyo denki steppers, it only required 38 volts to achieve 60m/min rapids and 5 m/s/s accelleration on a 29kg gantry. But that was after some trial and error with gearbox ratios and pinion diameter to get to the sweet spot.
 

the 2.9.4 image or the Pi 5 has been released and is on the Downloads page. It includes the 6.12 kernel which has been built from the official Raspberry Pi kernel source
 

What I don't get is that the change from Silicium (wrongly named as it was thought to be a metal) to Silicon predate Mendeleev's periodic table (actually this happened in 1823 and Mendeleev was born in 1834).
ISO publications refer to as Silicon.

I think it was either 2023 or 2024 that the Z80 finally went out of production.

Regarding the 555, most of the younger generation would probably grab an Arduino to flash an LED and think they are an electronics expert.

I truly think that the Arduino and it's ilk have "dumbed down" electronics as a hobby....oh hang on, we must call them "makers" now eh.

On no history is great, even recent history, tho Vale can't seem to get over it and still has to dig at Marc.

did you update all of the config files? that is why i wanted to see your var file. if it was out dated it means all the subroutines are also outdated which would be a possible contribution to your issue.

once you have verified all of your config files have been correctly updated for the latest probe basic release requirements, if you still are getting the error then come back and we will have a further look at it. in the interim it is always best to run a comparison on config folders when you do an update. in many cases if there are substantial changes to probe basic that include configuration changes such as subroutine file edit and or adds/deletions, if you do not have those things will not work as expected. a quick test is to try probing in the sim, if it does not fail in 0.5mm, then you know its a config issue.

royka wrote:

If you build LinuxCNC now from Master you don't have to patch the kernel anymore from 6.12+.
To be clear, of course you still need a PREEMPT_RT built kernel.
 

Do you know if this has filtered down to 2.9.4 yet ?

KrisJ wrote:

I'm trying to follow Deje63's step by step to build the RT Kernel but I end up with an error:
"reversed (or previously applied patch detected) assume -R?" when trying to run command
"patch -p1 < ../patch-$RT_PATCH_VERSION.patch".
I'm not sure what it meant so I tried to patch anyway but end upp with make throwing "Error 2" at me,.on makefile:1921. Any idea what this might be and/or how to rectify it?

OR even better if anyone might be able to share an .img with LinuxCNC working with Rpi5 and built on RaspberryOS Lite.
I can't get the GPIO pins to work with the distro on the downloads page and it looks like in the man pages that a build on RpiOS is necessary for this to work...

Edit: attached Deje's txt-file for convenience. 

 

I can't get the GPIO pins to work this doesn't help.
and it looks like in the man pages that a build on RpiOS is necessary for this to work... This is not true

Output from a halrun session loading the driver

halcmd: loadrt hal_gpio inputs=GPIO5,GPIO6,GPIO12,GPIO13,GPIO16,GPIO17,GPIO18,GPIO19 \
halcmd+:                                 outputs=GPIO20,GPIO21,GPIO22,GPIO23,GPIO24,GPIO25,GPIO26,GPIO27 \
halcmd+:                                 invert=GPIO20,GPIO27 \
halcmd+:                                 reset=GPIO21,GPIO22
Note: Using POSIX realtime
halcmd: show pin
Component Pins:
Owner   Type  Dir         Value  Name
     4  bit   OUT         FALSE  hal_gpio.GPIO12-in
     4  bit   OUT         FALSE  hal_gpio.GPIO12-in-not
     4  bit   OUT         FALSE  hal_gpio.GPIO13-in
     4  bit   OUT         FALSE  hal_gpio.GPIO13-in-not
     4  bit   OUT         FALSE  hal_gpio.GPIO16-in
     4  bit   OUT         FALSE  hal_gpio.GPIO16-in-not
     4  bit   OUT         FALSE  hal_gpio.GPIO17-in
     4  bit   OUT         FALSE  hal_gpio.GPIO17-in-not
     4  bit   OUT         FALSE  hal_gpio.GPIO18-in
     4  bit   OUT         FALSE  hal_gpio.GPIO18-in-not
     4  bit   OUT         FALSE  hal_gpio.GPIO19-in
     4  bit   OUT         FALSE  hal_gpio.GPIO19-in-not
     4  bit   IN          FALSE  hal_gpio.GPIO20-out
     4  bit   IN          FALSE  hal_gpio.GPIO21-out
     4  bit   IN          FALSE  hal_gpio.GPIO22-out
     4  bit   IN          FALSE  hal_gpio.GPIO23-out
     4  bit   IN          FALSE  hal_gpio.GPIO24-out
     4  bit   IN          FALSE  hal_gpio.GPIO25-out
     4  bit   IN          FALSE  hal_gpio.GPIO26-out
     4  bit   IN          FALSE  hal_gpio.GPIO27-out
     4  bit   OUT         FALSE  hal_gpio.GPIO5-in
     4  bit   OUT         FALSE  hal_gpio.GPIO5-in-not
     4  bit   OUT         FALSE  hal_gpio.GPIO6-in
     4  bit   OUT         FALSE  hal_gpio.GPIO6-in-not
     4  s32   OUT             0  hal_gpio.read.time
     4  s32   OUT             0  hal_gpio.reset.time
     4  s32   OUT             0  hal_gpio.write.time

This is from the latest image. Now if something doesn't work, please please go into detail. How are we supposed to fix an issue when you don't elaborate on what happens ? I can't tell you how frustrating this is.

This driver wont work on the RPi5 hal_pi_gpio has it depend on the bcm2835 headers, which is applicable for the Rpi4 & Rpi3.

 

Just a stab but have you tried ./macros instead of just macros?

It's an output pin of the cia402 component so the cia402 component writes the control word to lcec