Advanced Search

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

Aciera wrote:

QtPlasmaC stops immediately after probing when Torch On Enable is active — no error, just motion halt

Description:
I’m using QtPlasmaC with a Mesa 7i92 and emulating both the arc voltage (via encoder.00) and ohmic probe (via HAL comp comparing encoder.00.velocity-rpm to a threshold).

Arc voltage scales correctly: ~285 V when torch is far from metal, drops to ~0 V on contact.
Ohmic probing (IHS) works fine — Z stops at contact and lifts to CUT_HEIGHT.
If "Torch On Enable" is OFF, the G-code runs to completion (no THC, as expected).
If "Torch On Enable" is ON, the program stops immediately after IHS and torch ignition — no error message, just motion halt and GUI power-off.

THC is enabled in material (THC = 1), and Auto Volts is ON, so THC should use the sampled voltage after probing.

Not sure who posted this but it wasn't likely the 'PCW' we know. Seems like something went wrong somewhere so whoever it was please feel free to reregister.

-
A new member named "Roscom"
Unfortunately the forum shows the last valid user name when a member is deleted.
The above post was not made by PCW.

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

At the moment i cant run my routines with parameters.

easy to test:

#333 = 20
g0 g54 g43 z#333



 

Edit:
The error occurs on different ui, so it seems linuxcnc related. If other axis are affected, i dont know, because first z-movement lead to abort.
No matter if numbered or named parameter are used
Preview is working

gravedigger wrote:

Das Mint Ding ist eine heavy Distribution....wirkt sich das mit der Ethernet Mesa negativ aus oder packt das ein I5 PC mit 8 GB Ram?

 

Sorry, aber English gehts schneller,
If you ask "the internet" yes, Mint is a heavy distribution, but that has nothing to do with reality as windows is extremely heavy compared to it.
The reality is, Mint works perfectly, it is very reliable, well it is the most reliable distro for sure, and if it works for you, do not worry about what internet says.
Mint will happily work with 4GB of ram, so 8GB are fine, and if it helps, i use Mint on industrial machines in daily use, although i use the Mate edition, and on much older PC's without issues, ever.

Could you post your configuration files so we can take a look and see what the problem is?

The latest 2.97 version is also available in Debian Testing. The Debian Trixie release version includes 2.94 but it's a trivial 5 minute job to set up APT pinning to just get LinuxCNC from testing and everything else from Trixie as I show here:
forum.linuxcnc.org/9-installing-linuxcnc...97-and-later-forever
This will support any future LinuxCNC upgrades that are pushed to Debian