Advanced Search

Hey Folks, I threw together a wee python package to run on a standard LinuxCNC installation. I tend to have  an IP cam watching my machine but I know not everyone wants to do that. This package monitors the internal LCNC status and pings it out to a ntfy.sh  topic so you get "Machine stopped - ESTOP" etc. No account needed on NTFY. You can install the app for free on android or ios, and there's a web page on the LCNC machine showing the stats too.

github.com/bucklevision/Linuxcnc-notify/

Feel free to try it and see if it helps, give me a ping if you find issues or have ideas for improvements.

Free for all, no intention of that changing - LCNC has been a great tool for me, hope this is useful for some.

Hi Guys,
Looking for some help getting my table back up and running. Table is homebuilt running Linux 2.8.4 with a mesa 7i76E. I had no issues for the last year and half however today i tried to cut some simple 4x4 square plates in the plasmac extras section which I've used before but it would not load the g code or file. I managed to load previous saved files that i cut before with no issues. One thing i had noticed was the system had been connected to the internet which I'm not sure how this could have happened because i never connect this system to the internet, at least i thought. After disconnecting again I cannot load anything without error messages and i noticed sheetcam will not open when linux cnc is running. I have tried searching a fix but I am afraid of making things worse. I am not very good with any of the programming or technical issues and the friend i had helping with that is no longer with us. I attached a pic of the screen with messages that came up. This is when i first open it
ThanksAttachmentshttps://plasmaspider.com/download/file.php?id=98309

Всем доброго дня. 
Подскажите, можно ли достать такую прошивку, нужно: 1 мотор, 2-3 step/dir, 5 энкодеров и остальные разные кнопки, переключатели?
Или как можно изменить текущую прошивку, в какой программе?

BSAT wrote:

I know this is an old thread, but I have a 2020 1100MX, with the same issue.

Has there been a solution to this issue?

Thanks
BSAT
 

Have you checked or adjusted the servo tuning using Teknic's software yet?

The OP never reported back attempting this, and it's step #1 in identifying the faceting.

Step #2 would be checking the steps-per-unit  - can be calculated from the OEM motor config (also available in Teknic's software).

Step #3 would be to see if PathPilot, the Tormach hardware, and the Clearpath are capable of finer resolution.

Step #4 - if #3 is possible, change to finer resolution and make some test cuts.

PathPilot could be set to Clearpath's default steps-per-rev input, and there may be some room left given the Tormach stock max rapids:

 

I know this is an old thread, but I have a 2020 1100MX, with the same issue.

Has there been a solution to this issue?

Thanks
BSAT

sudo apt-get update
before
sudo apt-get install xxxxxxxxx

Or just delete it I suppose. Doesn't work anyway. Was running a part yesterday and lost all communication to the mesa card. fun days.... so much regression when I don't change anything... it's like "yay! it's cutting parts.. Nope just kidding, go sit at your desk and figure this one out now!"

cayenne@LinuxCNC:~$ sudo apt install galculator
[sudo] password for cayenne:
sudo: apt: command not found

This worked
sudo apt-get install galculator
But returned nothing but a bunch of 404s

I'm on ver 2.7.15 and everything I try and install including with the synapptic thing it all returns 404s

Hi everyone,

I’m having an issue with a CNC machine and would really appreciate your advice.

Until now, the machine was working correctly with an old LinuxCNC desktop PC connected directly via DB25. I’m now trying to replace that old PC with a newer mini PC equipped with a Mesa 7i92TF, while keeping the exact same configuration and existing wiring, without making any changes to the machine’s electronics.

The mini PC is connected via Ethernet to the Mesa 7i92TF, which is then connected to the CNC machine through the existing DB25 cable. Communication between the PC and the Mesa seems to be working correctly.

I reconfigured and remapped the axes using PnCConf to make sure each axis was assigned correctly. However, I’m experiencing some strange behavior with the motors:    
When I command an axis to move continuously, it barely moves.    
When I reverse the direction, the axis keeps turning in the same direction, as if the direction signal wasn’t being detected.

My first suspicion is related to the logic levels. The motor controller board is a X214650 and, as far as I understand, it expects 5V signals, whereas the Mesa 7i92TF outputs 3.3V signals. So it’s possible that the 3.3V signals aren’t being reliably detected by the controller board.

Would adding a buffer/level-shifting board, for example one based on a 74HCT245, solve this issue?    
Or do you think there could be a problem with my LinuxCNC configuration, despite remapping the axes with PnCConf?

I should mention that I’m a beginner when it comes to electronics, so please feel free to correct me if my understanding of the 3.3V/5V logic-level issue is wrong.

Thanks in advance for your help!

caretech wrote:

Thanks a ton, Greg. How soon will this hit Buildbot2, you figure?

Happy to help.

I honestly have no idea, as I don't use the buildbots/have any insight into them. If it/they are working it should be built by now.

You don't have to rely on them by the way. Building the project yourself is pretty easy and straightforward.

linuxcnc.org/docs/devel/html/en/code/building-linuxcnc.html

Hello

After almost 4 months of no news, I am able to give you further details and insights on the retrofit. In the meantime, we received a new machine (KUKA KR15-2 KRC2) which required a little bit of maintenance, and we were in need of some maintenance too, in the form of holidays . In the remaining time in between, all electronics of the control cabinet were removed (only the Indramat and the corresponding transformers have stayed) and the ancient components were replaced. Due to the new variable frequency drive, most of the original electronics weren't needed anymore. Therefore, a whole rebuild of the cabinet was the most logical thing to do.

By now, all components are wired in and the cabinet only needs a cleanup. We decided to build and wire all safety related components into EK1914 and EL1918 TwinSafe terminals. One of the EK1914 safety outputs drives a PILZ PNOZ s7 safety relais, which inturn cuts power to all "dangerous" output terminals. After the safety program is finished, all components of the mill can be tested. We did not test the communication between the TwinSafe PLC and LinuxCNC beforehand, so let's see how that will turn out For now, the cabinet is mostly finished and just in need of a cleanup.We are also using the aforementioned modified EL5021 terminals for the X, Y, and Z glass scales. Due to their minimum interpolation setting of 10 bit (=1024), we are theoretically able to read each 20 µm glass scale down to a resolution of around 20 nm. We do not believe that we are actually that accurate by any means, but we are indeed able to register every single move of each axis. Even if it is just caused by a finger pressing slightly on an axis. In the hot summer months, we also saw the mill getting bigger/smaller due to thermal expansion.

Our very first implementation of a homing component dedicated to Beckhoff encoder inputs is also working, granted not 100% as expected. The bugs still need to be fixed. Our installed VFD also needs to be tested. It interlocks the contactor for the hydraulic system opening the tool changer and vice versa. An inductive sensor is also mounted on the fan side of the spindle motor, which sends 2 pulses for every revolution of the motor shaft. These pulses are counted by the VFD for a potential PID loop in the future. It is also equipped with a brake resistor, which should allow us to cut some serious threads with rigid tapping by using the original gearbox. Speaking of which, that also needs to be tested. It received its own 16 channel input card and two EL7332 motor driver terminals to drive all three motors.

There still needs to be some serious work done, but we are getting there

If you want further details, just let me know and i will send you some details as soon as possible

sudo apt install galculator

Are you talking clock drift, always resetting to (eg) 00:00, a timezone offset, or something else? If it's drift, that's normal... clocks drift, some are shockingly bad. A lot of times you don't see it because OS's are configured to sync to the Internet regularly. You can check the time in the BIOS to verify that. If you don't have an internet connection on the machine, you're probably stuck with the drift/manually adjusting it occasionally.

Always resetting to 00:00 is probably a dead battery, timezone offset is likely misconfiguration or (if you're dual-booting) Windows and Linux fighting over whether BIOS time is localtime or UTC.

No calculator... pretty sure it has Python installed, which IMO is the best calculator around.

Thanks, that is very helpful.

Jogging being designed to be re-targeted while already moving is the key point I was hoping to confirm.

The note that each axis has its own planner and is not coordinated with the others is also important. That means FabScan should probably generate the desired Cartesian velocity vector itself, while LinuxCNC remains responsible for the real-time per-axis acceleration/velocity limits.

Your QtPlasmaC “scan mode” suggestion also makes a lot of sense. For early testing I can keep FabScan limited to idle/manual operation, but a dedicated mode that prevents conflicting user jogging would be a cleaner long-term solution.

This gives me a much better direction for the simulation and LinuxCNC SIM testing before I try any continuous motion on the real machine.

Thanks again!
Jeff

I'm on 2.7.15 How in the world do you make the desktop clock read bios clock and keep correct time? i'm a linux newb
Did this version really ship with NO calculator???