Advanced Search

"Correct" is subjective. I'm aware of MTConnect, but most people don't have home assistant and would have to build interaction routes. This uses existing, free apps and free brokers to push messages to your phone with no real setup beyond the initial apt install. I don't need the full data available on a dashboard, I just want my phone to ping if the machine has stopped. This maybe my misinterpretation of MTConnect, but it looks like a lot more install/config than I really needed for a simple task (Unless I'm mistaken - what's the route to getting phone notifications for someone without HA/HA companion app?).

If I run a suite of 4 machines and want to port their info into a hub for monitoring, sure. For me, in my garage, I don't want to install and secure a public facing HTTP route, then figure out some form of polling/monitoring/MQTT broker to collect the info, then push it to my phone. With this, I install the phone app, install the .deb on the CNC machine, scan a QR code with phone and it's done.

AFAIK MTConnect isn't backported to the current stable build, or any previous, so this won't help anyone with an existing install unless they update to a dev/nightly build?

Might it be said that if there's a rash of these lately, there's a need outside the current offering (or poorly documented within that offering if it exists?).

After updating the mesaflash app, I tried starting mesaflash. No errors were reported, however, the output were not toggling. Checking the man page, I could not identify any option to keep the pins toggling until the app was cancelled. Since the electronics are located on the back of the machine it requires more that 1-3 secs to move from the keyboard to the board to measure the outputs. Checking currently running programs (ps -ef | grep mesa), no app containing the string "mesa" was running. Is there a hidden option that will keep the app running until cancelled?

However, checking all of the outputs, all voltages were sitting at 4.92 v. What are the next steps for diagnosing issues with the 7i76U?

Kind regards,

Ist Ok mein Bedienfehler habe den Hacken bei Längkorr G 43 nicht gesetzt….
Alles gut
King regarde
Jürgen

Hi jjdege,

Thanks for the info, SPDL was intentionally left out as I only wanted one problem at a time to work on.

I am using stepper-online steppers with Lichuan controllers and I expected a few problems.

The axis are now moving so I am looking at how to set up the Stepper-Online A6 servo set up in csv mode.

For now I would set your machine up for immediate homing. Its described here but also read the whole thing (about 8 times as its important)
linuxcnc.org/docs/stable/html/config/ini-homing.html

If you want to use internal homing by the drive, I would leave that for now and set up homing by LinuxCNC until you have a better understanding.

Ok so what changed was the PC I swapped it out from a previous issue with a dell PC. I made this configuration from scratch following my notes from last time. This is my setup for the z axis.
 
Also I tried hitting prob test and that works fine it went down into the metal like its supposed to

If it worked before and you didn't update or anything, then it begs the question what changed physically with the machine?

The first move for every cut file is to move the Z axis to 5mm below the top of the Z axis' travel with the following line (for an imperial machine):

linuxcnc.org/docs/stable/html/plasma/qtp...20G%2Dcode%20program.

Also, maybe this diagram helps a bit:
linuxcnc.org/docs/stable/html/plasma/qtp...plasma:initial-setup

I am guessing that either something is up with your mechanicals, or some configuration setting got changed.

Hello,

I tried to place a PayPal order on the website and was unable to complete checkout due to technical issues on your end.

Shipping Name is a required field.
Shipping Name is a required field.
Shipping Street is a required field.
Shipping city is a required field.
Shipping Status is a required field.
Shipping Zip Code is a required field.

These form fields were properly filled in.
Can you look into the website issue?

ich habe jetzt ein bisschen mit KI rumprobiert. Im PP Modus hatte sich der Motor mal gedreht im CSP Modus nicht mehr. Scheinbar hatte irgendwie die DC Synchronisation gefehlt. Hier mein aktueller Stand:Wir haben bereits bewiesen:

• EtherCAT OP ✅
• DC-Synchronisation 1 ms ✅
• CSP PDO-Mapping ✅

• 0x607A

  über PDO erreichbar ✅
• Motor reagiert auf kleine CSP-Positionsänderungen ✅
• aktueller Fehler

  0x603F = 0

  ✅

ich würde jetzt gerne G0 X10 in LinuxCNC eingeben und gucken ob der Motor sich dreht, aber ich kann keine Referenzfahrt durchführen. Und ohne kommt jedes mal die Meldung Bewegung würde pos Anschlag von Achse überschreiten.
 

Take the time to read the cia402.comp source and example. I was wrong, cia492.comp includes a pin to select PV (velocity) mode which is what you want. 

I'd probably edit the name in your XML to be S0 instead of D1. this will make more sense when assiging pins to spindle.0
There are pins for target_velocity and actual_velocity (encoder feedback) so you are getting close. I think that your spindle speed-cmd pin should map to target_velocity and be sure the encoder is properly scaled.
I'm not sure how to map spindle.0.on to enable the motor.
spindle at speed would use the near component between  target_velocity and actual_velocity
to capture a long list of pins you can add > pins.txt to the show pin command to write output to a file

JT is expressing a view some developers have. Personally, I find there are so many simulations now the alternative is downright confusing  when looking for a specific sim. I think the solution is refactoring our git repo to support additional guis in a plugin type arrangement. That is not a trivial task.

20 or 25 MHz (2.4x or 3x faster than the default 8.3333 MHz), works fine with no skew added.
I would be comfortable with those settings.

The frequency value you set will be rounded to the closest available frequency
= an integer division of the 100 Mhz FPGA ClockLow. This is easy to test with halshow.

As you go faster, the timing margins become smaller and you must adjust to the delay in
the actual hardware multiplexing with the skew adjust (in ns) but at the higher speeds
the timing variations over voltage and temperature limit the practical maximum.

That is, I can get all encoders to work with a 50 MHz mux rate (and 20 ns skew) but I would not trust
it without doing at least a temperature cycle.

Timing errors will show up as even/odd encoder swaps or crossover between even/odd encoders
so don't experiment on a powered servo system...

tuxcnc wrote:

rodw wrote:

I don't like using backports. Never have used them.
 
"I don't use it" and "I don't like it" are not substantive arguments.
The problem is that there are newer versions of the libraries in the newer release. First of all, it is about Python, in which the authors constantly change or remove something, so even relatively new programs (from a year or two ago) do not want to run, or some of their functions do not work.
However, backports repositories are optional, you can activate them, install only what you need and then turn them off again.

The reason I don't like backports is it can land you in dependency hell as you point out. That's my substantive argument.
I've been in this position needing a later kernel to support my hardware. Today, I would either compile the kernel and be done with it or use apt pinning to be very selective on what packages I obtain from unstable.

Hello everyone I have a new issue with my plasma table. So after I home my machine, load the file, zero the machine, and click cycle start my z axis torch travels up into the home switch instead of going down and probing the sheet of steel. I ran an mdi comand "g0 z-.5 and when I hit enter the torch moved down -.5 like it should so I dont think anything is reversed. The gcode file I am using worked in the past so im am just at a loss. Is there a certain amount of travel the torch is supposed to go up initially that I could maybe adjust to fix this? 

 
 

You could use one of the Mesa 7i76e's not very accurate analog voltage input pins and a 10k resistor to form a voltage divider. at 25 deg C, and 24 volt field power, the voltge will be 12 volts. You might need to scale this with lincurve or a custom component. Accuracy of +- 2 degrees due to 8 bit conversion is probably OK for this application.