Advanced Search

Hey Tommy,

Thanks. I actually just got a response from Peter.  He gave me the same link you gave me but told me there is a firmware that already has the modifications that I need.  It's called 7i96s_pmd.bin.  So it seems that as long as I can get this to flash I should be good to go as far as listening to the PWM from the Powercore from Rack Robo goes. 

Assss long as the Mesa board can pick up a 3.3v signal on that pin.  It seems that is what the Powercore is putting out as its PWM signal. I can also ask Peter about this and worst case I can run the input into a MOSFET or something similar to up the voltage into the Mesa...

Best,
-Dylan

Hello,
I'm getting more familiar with LinuxCNC and Mesa boards, converting a Biesse Rover 13s and have a 7I96s step and direction interface along with a 7I77 analog servo interface connected via the P1 expansion connector. I also have one 7I84 I/O board connected via the TB2 sserial and all is well, I can command the outputs etc. from halshow at all the boards but I need to connect two more 7I84s. I also have the 7I94T anything I/O Ethernet card but I'm using ethernet already on the 7I96S with 10.10.10.10. Should I reset the 7I94T IP to something other than .10 and use an ethernet switch or is there another way to use multiple sserial channels from the 7I96S?

By the way I really appreciate all the others that have gone before me and made this all possible! Thanks for the help!

I was typing up a post to ask for help getting LinuxCNC 2.9.2 running on a Raspberry Pi 4 B attached to a Raspberry Pi 7 inch Touch Display, when I finally figured out the solution. Thought I'd still make the post for helping others or possibly even future me if I have to rebuild this system one day.

The Pi Touch uses DSI for connecting to a Raspberry Pi and seems LinuxCNC doesn't have the required settings enabled in the config.txt by default. Not really a surprise as its probably an unusual pairing of hardware and OS.

The solution was adding the below text to config.txt

It should work indeed when selected fully preempted. At least it worked for me until 6.11 (after patching). What's strange for me is that when it's set manually to rt prio it works

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 ?