Put it this way, if the RPi5 goes bad for whatever reason, you'll have to get a new Raspberry whatever, but if you go with the 7i96 any machine with an Ethernet Port will slip in, copy your config over and you're good to go. Hardware step generation, Mesa, et al, will be smoother than software step generation.

Good evening,

It appears the Wiki is having trouble. Is there an alternative place to get the information?
I am getting a "Site not found" error.
I cannot figure out how to include a screenshot.

Thank you,
-T

Hello all.  It's been a couple of years since I got my machine, a 3 axis knee mill with steppers and linear encoders, working and I'm now finally getting around to something I've been wanting to do for a long time but I've probably forgotten most of what I learned while setting up this system and would rather not break it so I thought I'd ask first before I start tweaking the cfg/ini files. 

The goal is to increase the accuracy.  When I command it to go to a position it gets close (within .001) but I'd like to halve that if not better.  Do I remember correctly that this is the DEADBAND value in the .ini file?  It's presently set to .001 (at each joint), I have 5um encoders which my notes say corresponds to .0002" so I'm thinking I could go to a DEADBAND value of .0005 and maybe all the way to .0002.   My stepper controllers are presently set at 200 steps/rev, I can increase that by A LOT with DIP switch settings.  I have .200"/rev leadscrews and 1:2 pulleys (big one on the leadscrew) so one motor rev is .100" of movement.  At 200 steps/rev that corresponds to 2000 pulses per inch which is what I have for the STEPGEN_SCALE value.  That means I have .0005" per step.  So that has me worried that changing the DEADBAND value to .0005 might cause it to start oscillating since I'd be requiring that it gets withing one pulse.  Does it make sense to change the stepper controller DIP switches to 1000 steps/rev  and the STEPGEN_SCALE to 10000 to avoid this?  That would change it to .0001"/pulse which is smaller than the encoder.  Does the position feedback handle the situation where it sends multiple pulses before it sees a change in the encoder?  If I change the DEADBAND and STEPGEN_SCALE values in the .ini file do I have to change anything in the other files to correspond with this? 

Am I correct that this likely changes the max speed I can run at.  What breaks it I try to jog it too fast.  I'm presently using these values:

STEPGEN_STEPLEN = 2000
STEPGEN_STEPSPACE = 2000
STEPGEN_DIRSETUP = 2000
STEPGEN_DIRHOLD = 2000
STEPGEN_DIRDELAY = 4000
STEPGEN_MAXVEL = 0.25
STEPGEN_MAXACCEL = 0.25

BTW, all three axis are the same.

thanks in advance for any input
 

Just seeing this now. No I did not find another way. It works for me with the extra integration loop. My purpose was to machine some parts. I contacted lichuan and they said everything was fine on their test stand. It is sort of good to see someone else has the same issue. I have no other idea how to resolve it.

If you have field power and neither CR15 nor CR16 light, its possible the 7I77D was damaged as well.
 

Thanks for that clarification, unknown!

I’m running Meanwell PSUs so very glad to hear the vote of confidence in those. Also good to know your powering sequence, and that the DB25 powering solution is the preferred one. 

I got the chance to power the 7I77D today, and discovered that it lights CR1,3,6, and 7, but CR15/16 never light. Confirmed with both my meanwell supply and my bench supply. I’ve ordered a 7I92TM and will RMA the 7I92T I have, but this would appear to mean that the 7I77D is not functional. I don’t think I have a machine with a parallel port on it, so I’ll likely wait until my new 7I92TM arrives, verify it works, and then connect it to the 7I77D and attempt to reflash the firmware on it. Does that seem like the right approach? Or does CR15/16 not lighting mean that board is also probably damaged and needs RMA as well? 

Thanks! 

 

I started a place to document gladevcp builtin panels:

linuxcnc.org/docs/devel/html/gui/gladevcp-panels.html

Feel free to add some more detail for people to understand how to add your probe screen.
And thanks for adding your small probe panel!

Thanks Andy.

Is the rPi GPIO interface considered fully baked, or is the Mesa 7i96S the smart bet? I would totally love to avoid the $150+ for the Mesa, but only if that does not then cost me an additional $300 in labor time.

BB

This may be relevant  forum.linuxcnc.org/38-general-linuxcnc-q...ove-only-following-e
Start from the end where the final setup is.

of course here are my files, I tried one configuration with fb that works but I still don't know in practice if it works well, definitely try it if you are able to see why this one doesn't work. thank you very much




# --- FEED SPEED POTENTIOMETER'S ---
[url=https://www.facebook.com/hashtag/bit?__eep__=6&__cft__[0]#BIT direct value
setp halui.spindle.0.override.direct-value 1
setp halui.feed-override.direct-value 1
# SCALE
setp halui.spindle.0.override.scale 0.01
setp halui.feed-override.scale 0.01
# scalemax
setp hm2_7i96s.0.7i77.0.0.analogin1-scalemax 150 # spindle
setp hm2_7i96s.0.7i77.0.0.analogin0-scalemax 120 # feed
loadrt conv_float_s32 count=2
addf conv-float-s32.0 servo-thread
addf conv-float-s32.1 servo-thread
net analogin0 conv-float-s32.0.in <= hm2_7i96s.0.7i77.0.0.analogin0
net analogin1 conv-float-s32.1.in <= hm2_7i96s.0.7i77.0.0.analogin1
net analogout0 conv-float-s32.0.out => halui.spindle.0.override.counts
net analogout1 conv-float-s32.1.out => halui.feed-override.counts


youtube.com/shorts/Htwi7ruTzAQ?si=xwU-Dm2b8Pwv2qeN  


 [/url]

gravedigger wrote:

Das RASPI PI5 läuft absolut unzuverlässig  und stürzt unvermittelt ab mit einer zweiten Netzwerkkarte, aber das WLAN hab ich als Anfänger nicht hinbekommen mit den Anleitungen.
Dann hab ich das offizielle Image 2.9.2 mit einem Micro-PC verwendet und auf 2.9.7 upgedatet, welches aber auch wieder irgendwelche Fehlermeldungen produziert und die Ethernetverbindung zur Mesa abbricht (Realtek Treiber und RASPI Image Meldung).

 

Bei mir läuft das Debian 12 sehr stabil. Ich habe testweise das aktuelle, auf Debian 13 basierte Image kurz getestet, habe mit dem Raspberry 5 8Gb extrem schlechte Latenz.
Was WLAN angeht, ist das eher ein Hardwareproblem. Meiner muss schon 10cm so neben dem Router liegen, damit er sich mit dem Netzwerk verbindet. Bluetooth ist auch sehr schwach. Meine Kopfhörer haben Aussetzer und sobald irgendetwas zwischen Raspberry und Kopfhörer liegt, bricht die Verbindung komplett zusammen. Ich vermute, das ist beim Raspberry entweder absichtlich so gemacht, damit er weniger Strom verbraucht, oder irgendein BGA ist schlecht verlötet.Wenn du eine zusätzliche Netzwerkkarte und einen SSD Adapter huckepack hast, schirmen die das Signal zusätzlich ab. Evenetuell hat eine davon einen Defekt oder einen schlechtern Treiber, worauf die Instabilitäten zurückzuführen sind? 

Yup, same-same. This one was just an accident, usually it's me doing something wrong...

Placed the order for a new one today,

While waiting I've got to find a better solution to using these fine wires from the sensors and pendant into the terminal blocks. Maybe crimp/solder some JST pin ends or something.
M

I managed to make some progress this weekend.
I can now command all 3 axis. Motors are hunting a bit, but I will send time to tune them later. Servo drives/ motors have a high pitch noise when enabled, but I will live with that till I can upgrade to brushless DC servos at a later date.
Next would be to connect rest of the IO and get it to interact with linuxcnc.
Really happy to have things moving on command and grateful for the help from members here!
Good week to all