Advanced Search

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???

Linuxcnc has no ability to 'drip' feed gcode commands.
You can stack MDI commands but that doesn't always work the same as a program.

I realize neither of these is what you want to do anyways.

So the other two ways to control movement is jogging and external offsets.
Jogging seems to most appropriate for what you are doing.
jogging is made to be re-targeted mid movement.
Each axis has it's own planner and they are not coordinated with each other.

If you want to coordinate with QtPlasmac, best to have them integrate a 'scan' mode to lock out the user from trying to jog but otherwise I think if idle, Qtplasmac won't mind.

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

QtPlasmaC updates - Master (v2.10):

• fix cut recovery bug
• fix user button removal
• fix some button interlocking templates
• fix user manual URL

Just pushed a commit that should fix this (and a few other issues).  This is entirely my fault, caused by a refactor of the way we were doing button interlocking (enable/disable).  As it turns out I trimmed too much fat and completely broke cut recovery.  I am honestly not sure how I missed this, but I appreciate you pointing it out nonetheless.  It's been broken since the beginning of Feb 2026.  Which either means not many people use QtPlasmaC on the master branch, or not many have cut issues requiring cut recovery, or both... 

I apologize for the inconvenience I caused.  

Please let me know if you run into any other issues!

Happy cutting.

-Greg

  Is it unrealistic to try and run this on 7.2.15 ?