Advanced Search

You should enter problem-solving mode and try to solve it

First, verify that the encoder as such works and gives the right values.
Check schematics and hardware setup since you use your own pcb. A and B must go in to PA0 and PA1. They electric signal must be NPN open collector. Use interface circuitry if needed.

Check that it counts up and down using the debugger.
Add a line first in loop()Use this a breakpoint and watch that pos changes value as you rotate the encoder shaft.
Read up on debugger usage if you haven't used it before. But it is basically just to start it with Run -> Start debugging and then single step into or single step over and watch values in the left column.



 

Deleted a bunch of suspected spam setups.

royka wrote:

Perhaps something wrong with the kernel config? You could try to install the kernel deb that I uploaded to see if that helps. Otherwise you might need to install more software, just install a complete desktop will be the fastest route to find out.
 

I compiled a desktop one and I've installed the deb kernel real time, and that fixed it. I didnt change much in config file, the only change was enabling fully preemption and I added the patch you provided and set the gpu governor to performance.

I learned I could measure EMI in my system by using a floating wire ran along the wire races containing my control and logic signals. I get the e-field noise connecting my probes ground to the panel and probe to the end of the wire and b-field by grounding the other end of the floating wire in the same probe configuration. I would like to connect a physical probe to a mesa card input but im not sure yet on how to go about it. 

I would need a input that could read voltage and i would assume i would need to wire a BNC connector to that input I have a 7i96 and 7i84 is there an input suitable? I dont know enough about what Im trying to do to actually pull it off. But when i started doing this cnc project few years ago I was in the same any input would be helpful. I think having a way to see and track emi over time would be helpful troubleshooting the tinkering and upgrading i seem to do i could see if emi is affecting performance in a measurable way. it would be cool to add a tab to my gui with those halscope screens so i could take a look at a glance theres just a lot to this idea im still unpacking and brainstorming 

Perhaps something wrong with the kernel config? You could try to install the kernel deb that I uploaded to see if that helps. Otherwise you might need to install more software, just install a complete desktop will be the fastest route to find out.

I followed your advice. 
 
 
and enable 
 
Create new esi, connect pdo 

Create a new config and find the pin command inside Hal.
 
I get response in encfrequenry when I spin the motor
And there is response in encpos but not perfect. When I don't set scale, the encpos number will change up and down but not much.
When I set scale, the encpos value will become decimal as shown in the picture.

What should I do next?
 

Heres the latest update on the project. I designed a water table 10.5 x 10.5 made from quarter inch thick Steel. I may increase size to 10.5 x 15.5 but not sure yet. It's pricy in material table so far weighs in at around 7000 lb and I am still going to add more support to it. It has removable slat bases that can be picked out of the bed with the crane for cleaning. I am designing for about 12 inches of water from lower to raise and shooting to be able to keep the slats 2 inch under water. I made the slats 6 inches long 1/8 thick every 2 inch. Do you think this is overkill??? 

I think my post has delve past the computers and hardware category on this board and more so turned into a full on build thread. If a mod wants to move the thread it would proably make sense. 

Lcnc, Rio, Modbus all looking good. GTK not so much though (Failed to load module "atk-bridge").

Are you on a VM or accessing your linux session via VNC or XRDP by any chance? Additionally, it would be a proactive move to list/describe all the GTK debugging steps undertaken so far so that others seeing this can be updated on your progress. Bet it's an easy fix.     

No iso actually, it's a tarball that gets deployed on either an HDD, SSD, USB drive or NVMe and it's not live.

Will try irqaffinity=0 -- I also need to play with nohz_full rcu_nocbs and isolcpus.

edit: Currently battling qtpyvcp on Gentoo. I do have FlexGUI working flawlessly on it. I have to use the `pyside6` branch in qtpyvcp and I've been working with Turboss on fixing the issues but there's hiccups in Gentoo itself that I'm hitting with it that I need to sort out with the developers. Will update soon.

royka wrote:

As far as I know it shouldn't matter if you install it during compilation, otherwise it would be fixed with "apt reinstall linuxcnc-uspace".
What do you see with: uname -a ?
What do you see in the terminal when you start with: latency-histogram ?
 

The output of uname -a:
root@orangepi4-lts:~# uname -a
Linux orangepi4-lts 6.12.1-edge-rockchip64 #2 SMP PREEMPT_RT Fri Nov 22 18:00:26 +0330 2024 aarch64 GNU/Linux

and when running latency-histogram I get:
Note: Using POSIX Realtime

and just this, seems like waiting for something and nothing shows up any more

@Lcvette -

I'm still using the combination of carousel.comp and PB's parameter numbering I came up with a while ago.  In short, I substituted carousel.comp's internal pockets-to-move for the PB macros.

I've not updated to master yet to see if the tool number >199 issue has been fixed by the recent commit.

And regarding a change-to-tool not in the carousel, I think you all sorted that one out recently... but I haven't tried it yet to see if your prompt works.

Once I get the tool number <199 sorted, it'd be interesting to try an experimental config and see if the LCNC native tool number vs pocket issue works and the PB macro math & parameters can be abandoned or simplified.

On the other hand, even if the pocket issue is solved inside LCNC, it might still be necessary for PB to duplicate/mirror tool numbers and (maybe) pockets in some parameters so that some PB features are still viable.  Like checking for probe tool number, or (eventually) doing tool probe radius offset for tools over a certain diameter.

I'll try and do that tomorrow.
 

Der Link geht wohl bei mir nicht.

I habe kein OZ, aber soweit ich das sehe sind die sehr ähnlich. Die Winkel und Längen sind anders, aber das Grundprinzip ist gleich.

Mit selber machen meine ich, a) entweder den Einsatz, siehe Bild, passend zum Spannzangenfutter machen. b) sowohl Aufnahmene Kegel, als auch Einsatz selber drehen.

I have some logs created. In the logs you find the different rio.hal and rio.ini configurations.
Twopass disabled
loadusr -w classicladder --modmaster vfd.clp in postgui_call_list.hal
pastebin.com/61urYP3n

Twopass enabled
loadusr -w classicladder --modmaster vfd.clp in postgui_call_list.hal
pastebin.com/bKd8N5Ex
 

It'a already fixed in 2.9 -just not released yet.