Advanced Search

Thanks for your patience.
I get that I can find all the available pins using the methods above.
What I don't get is that when I use mesaCT or PNCConf to create ini and .hal files and have selected say channel 0 for the X encoder, The physical pins that will be used don't show up the hal file.
Its to me like when you make the selection in the gui, some things are automatically known like the pins, and the hal file doesn't need to show all of them, just ones you might need to edit.
So the hal file isn't the place to look for the full details of a setup right back to pins.
I will learn this system...

The hal file is what connects things (it does not show all possible pins) ,
so to use an encoder input, you would do something like this:

net min-x <= hm2_7i92.0.encoder.01.input-a

You can use halshow to browse pins and parameters:

 


or list all pins/parameters by running this command:

halcmd show all

from a terminal window when LinuxCNC is running.

You can also

halcmd show all > all.txt

to create a copy/paste donor file when editing hal files

if you just want hardware pins/parameters

halcmd show all hm2

will do

If you just want encoder pins/parameters.

halcmd show all *encoder*

or

halcmd show pin *encoder*

if you just want to see encoder pins.

Maybe post your hal and ini files.

I guess that's the bit I am missing.
In the hal file, there are no "input-a" anything for the X,Y and Z encoders so I don't get how lcnc knows what anything is connected to.

Sorry.

The raw encoder pins have names like:

hm2_7i92.0.encoder.03.input-a
hm2_7i92.0.encoder.03.input-b
hm2_7i92.0.encoder.03.input-index

Thank you for helping. it is working. having some troubles with the WIFI see new work can't connect. What file are recommended for the byte to bot set up with the Parallel Port Raspberry Pi Hat and 5 axis breakout board.

Hi Tim,
your measurements are correct,
the code is wrong

I have fixed the shiftreg plugin,
but the 6.4Mhz of the w5500 are correct,
more is not possible with the ice40up5k on 30Mhz clock.

Thanks !

Joco wrote:

And that behaviour continues under scurve planner?  That was what I was referring to. Not what standard planner does.

@Joco - my apologies, I completely misunderstood your original warning.  I thought you were concerned that the current TP maybe didn't lock out FH and motion-inhibit as advertised, and perhaps that situation was carried in to Grotius' s-curve TP.

I have not tested the s-curve TP's behavior.

Sorry to all for the unnecessary tangent.