Advanced Search

Start with
DIRSETUP = 20000
DIRHOLD = 20000
STEPLEN = 5000
STEPSPACE = 5000
And if it works, change only last two to 4000, test, 3000 etc, until you notice missed steps, then add 50% more to that, i would add 100% just to be safe.

Is the tittle OK now?

www.phoronix.com/news/Linux-6.12-Does-Real-Time
6.12 does not need patching for AMD64 according to the above, it should work with just setting the preemption to full. That needs to be tested.
The list of all architectures that have ready made debs for 6.12 RT.
packages.debian.org/search?keywords=linux-image-rt
And yes, i know patching sometimes does not work as it should, but can not recall what would cause that as last i did patching was when Linux Mint 17.n came out.
And yes, we do need evidence of it not working on AMD64 or X86_64 (there are no new kernels for X86 for quite some time).

Anyway thanks for the link, just tried the kernel from the link and that one works correctly indeed. Still a mystery for me while mine doesn't get detected, because rhey're compiled with fully preemptible (realtime) in menuconfig.

Why compiling myself? Because I use it on a pc with Fedora and an Orange Pi 5. I'll dig further into it.

If i have a maximum frequency of 500k(pps) and a minimum pulse width of 1us how do i convert those numbers into the step and direction timings of a joint that i put into my ini file?

In the other terminal you can read "PREEMPT_,RT".

In the screenshot of the whole screen (where I put the rtapi processes manually on the FIFO scheduler with rt priority) you can see from the result that it's definitely a realtime kernel, but somehow just not detected correctly since 6.12.
Do I really need to send a proof that it's the same with x86?

It's a bit annoying that the title got changed to something that attracts less attention, while it's not even limited to only that device/architecture.

Since you didn't reply on it but you did reply on other topics in this section I assumed that you didn't read it. So by trying to prevent of getting a lot of noise in this topic (didn't work) I pushed the report button.

OP-

First thing to do is run LCNC from the command line, and turn on some level of debugging in the INI file.  That's helped me catch 'backstage' problems, or at least I can figure out where to start looking.

Then run LCNC - with and without twopass - and see what is happening in the terminal window.

I suggest changing the terminal preferences to 'unlimited scroll-back' before you start.

Once you capture a problem ion the terminal, take a screenshot and post it up here.

Nothing on the screenshots says it is a fully preemptible kernel in use, and it is also noted by LinuxCNC in the terminal saying "using posix non-realtime".
Why the report? You already said that here and it was not changed (the tittle) as there is no evidence the normal AMD64 kernel also does the same thing, both screenshots contain only Orange PI.
Instead, try patching the kernel again and choosing fully preemptible in menuconfig (was it called that?) ... but then again, why patching, there are ready made debs for AMD64 with RT patching already done, no idea if there is one for OPI though.
AMD64:
packages.debian.org/experimental/amd64/l...c6-rt-amd64/download
Nothing for AARCH64 though.

It is not an error as noted on the warning, well not always, so you do need to test on a machine or use a DVM to check the output pins on the parallel port connector.

You are correct.  I forgot to sudo the first time.
I did try to run LinuxCNC with the new address.
I got the same error with the new address.
The demo runs.  Computer is not connected to the mill so I don't know if signals are going to the port.
Thanks for your assistance. 

 

There are some precise water leveling systems like these
www.precisiontools.biz/tools2/pwl/
www.wylerag.com/en/products/communicatin...icating-water-level/
www.wylerag.com/fileadmin/pdf/manuel/Com...g_Water_Level_77.pdf
They follow the curvature of earth so there are pretty accurate
for linear leveling ways when build up a machine or machine leveling...

Because water is polar molecule there is surface tension between water and hose-cups so if forms meniscus at the edge
but because cups are 50mm x 50mm meniscus formed only at the edges of cups and not in the center.
Addition of surfactant to water helps to reduce water tension.
A micrometer with a needle attached to it probe water surface and detect
differential height between surfaces.

Can resistance probe modified and used in Z axis instead of micrometer
to detect touch with water of other liquid?
This will be very simple to level machine and machine ways
with very much accuracy without special instruments.
Dro of Z will show the height difference instead of micrometer and detection
touch of probe with liquid by vision.

Because deionized water has more consistent density and DI water is not conductive
so resistance probe will be useless can be used capacitance probe ?
 

It should be here
www.mesanet.com/software/parallel/7i96s.zip

Aciera,

I shot Peter from Mesa an email and he responded saying that I could custom configure the firmware for the 7I96S using the 'periodm' command to read PWM signals. He said that redefining one of the encoder inputs would be best. I will post here as I learn more. Here is the info on said command:
linuxcnc.org/docs/scratch/html/man/man9/hostmot2.9.html#periodm

I believe that I can re-flash from the terminal on my machine. I will probably run the firmware past Peter before flashing.  Here is a couple links that explains re-flashing. Tommy has posted on one of them, perhaps you can weigh in..
forum.linuxcnc.org/38-general-linuxcnc-q...ashing-mesa-firmware
www.forum.linuxcnc.org/27-driver-boards/...a-card-7i96e-and-7i8

Does anyone have a source for the standard firmware that comes on the 7I96S? I need a base software to modify.


About M52. I should be able to edit my GCode post processor to add M52 P1.  Modifying the post processor is not too difficult using Visual Studio Code.  I assume this just needs to be posted once at the beginning of the gcode file to put the machine into adaptive mode? And maybe once again using P0 at the end to turn it off..  I can have a separate post script for EDM.

I haven't had a chance to do any research on running a PID loop inside of HAL yet.  I plan to do that and will respond here with questions and comments.  I think I should be able to figure it out using a combination of the LinuxCNC resources and ChatGPT.  I am currently out of town for thanksgiving and will not be able to test anything on hardware until I get back. 

Best,
-Dylan

In addition to setting the PWM mode to up/down, you would need to change some names:

ORIGINAL

net Xpwm pwmgen.0.pwm
net Ypwm pwmgen.1.pwm

net Xdir <= pwmgen.0.dir
net Ydir <= pwmgen.1.dir

net Xdir => parport.0.pin-02-out
net Xdir => parport.0.pin-04-out
setp parport.0.pin-04-out-invert TRUE
net Xpwm => parport.0.pin-03-out

net Ydir => parport.0.pin-05-out
net Ydir => parport.0.pin-07-out
setp parport.0.pin-07-out-invert TRUE
net Ypwm => parport.0.pin-06-out

To something like:

net Xup pwmgen.0.up
net Yup pwmgen.1.up

net Xdown <= pwmgen.0.down
net Ydown <= pwmgen.1.down

net Xdown => parport.0.pin-02-out
net Xup => parport.0.pin-03-out

net Ydown => parport.0.pin-05-out
net Yup => parport.0.pin-06-out

Note that you may need to change the sign of the PWM scale or swap the up,down
parallel port pins to get the correct feedback direction.

oh, thats good to know, I will try that in the morning when I am at the shop.

Thanks.