Advanced Search

Murphy wrote:

Does this look ok to get the encoder PV1 counting? PV1 should be the MPG socket. I don't know if I have a hardware issue or code issue. Also does the nvmpg.so need to be compiled first? I'm using an adum1200 to bypass the opticouplers. PV1 does not count when I move the encoder in Halshow

Hi, are you using the nvmpg or just an encoder?

The nvmpg component does the communication for the screen updates and button press receptions. The nvmpg LinuxCNC component needs to be enable in the ini file to use the remora-nv-mpg.hal file. Encoder pulse counting is done in software on the LinuxCNC side. So slow speed counting.

Encoders require the QDC module to be enabled in the config.txt file.

eg  Remora-RT1052-cpp/LinuxCNC/ec500-rt1052-DMA-ENC.txt at main · scottalford75/Remora-RT1052-cpp

Example encoder hal file

Remora-RT1052-cpp/LinuxCNC/remora-ec500-DMA_closed_loop/remora-ec500_closed_loop.hal at main · scottalford75/Remora-RT1052-cpp

That's very kind, thank you.

Check with "ls -l /boot" if all links are correct. With Armbian for example the Image file is a link to the used kernel. To relink you can use "sudo ln -sf your-rt-kernel Image" and also check for the uinitrd link and to use the right dtb for that kernel version.

I saw that it's a rk3399 indeed, but here it also worked great for a s912 sbc so it might be a good base for yours too.

It's only those two buttons and I already have a fix in my mind as soon as work is over I'll implement that.

JT

Ok never mind i did have a very small blow out I didn't see in the tip. so that would account for the raised HC look

That's it, I'm now able to generate steps up to 125KHz !
You were right, using the DMA version did the trick !
I'll check the posts talking about DMA.
Again, thank you royka

EDIT:
For those wondering, the 125KHz limitation comes from the step length and step space both set to 4us. F=1/T so F=1/8us=125KHz everything works out !
The limitation comes from my JMC Integrated Servo, they don't work is I lower the step length.
That's kind of weird because the datasheet claims they can go down to 2.5us...
I'll check the signal with an oscilloscope.

Yes that one was the default. I just switched to the one Phil provided. Was able to run the materials in QTPlasmac but I seem to have an issue in Height control or maybe it was the consumable guess ill check that real quick...
Ok those look good but I'm getting intermittent raised cuts probably a settings issue in my HC but I've seen some PP create issues there as well. Im using the MESA THCad2 so its more than likely I haven't dialed that in correctly yet.

Thank you guys, I connected before the choke coil, there are 3kV capacitors so the voltage can't be higher than that. I used HV resistors.

Now I'm stucked with the arc voltage.
I placed a 9V battery on the input with a potmeter to test it. I set and calibrrated everything, encoder.0.velocity net to arc-voltage-in, the value changes with the pot but the arc voltage on the GUI and arc-voltage-out signal does not change, stays zero. Tried different scale settings, no result.
How to get that voltage?

Seems like you’re still using the default post processor instead of the one Phill posted…

For the lowest latency, you might have better luck with RTAI than PREEMPT_RT, assuming the BIOS isn't buggy:

forum.linuxcnc.org/9-installing-linuxcnc...ng-rtai-debs-for-2-9

If you need help, let us know!

Thank you for your reply

Indeed, it's these buttons in particular that I was talking about.

I didn't know if there were others involved, as I haven't tested many of them.
If it's only these two that are hard-coded, I don't think it's a big deal.

royka wrote:

Besides patching you should still choose full realtime in the config. After entering "make menuconfig" => General setup => Preemption Model => Fully preemptible kernel

Here are the rt config settings that works best for the rk3588:
github.com/orangepi-xunlong/linux-orange...s/rockchip_rt.config
 

Thnks, I've done all that but didnt work. I chose fully preemptible kernel.
my problem is after compilation, and after installing the deb file of rt compiled kernel, the kernel doesn't switch to the rt one and still boot with the old kernel. and also I manually changed the boot.cmd file in the boot directory, after doing this the kernel doesnt boot up at all and just stuck in that stage.
by the way, my orange pi 4 lts has rk3399 not rk3588.

tommylight wrote:

Nope, not RT, should have RT in the name there.
Run latency-test or latency-histogram , just in case.
 

Yes, I know. I couldnt switch to the rt kernel yet.

Here's the one I use. It's a Travel Distance & Lube component. Rather than time based. 

That way you can leave the machine idle for a day and the oil jar won't empty itself in your coolant reservoir.

e.g. at every 3000mm travel in the Z, lube for 2 seconds. 

Must have (imho)  
 

Let me think about this a bit... the E Stop and Power button text is currently hard coded.

JT