Advanced Search

I need hardware suggestions.  There seems to be a gap in my knowledge, and in my research.

I just got a new CNC router, and it came with a Grbl-based controller.  I always used LinuxCNC in the past on my DIY machine, and I can already tell that I'll probably be happier if I switch to LinuxCNC on the new one.

The most recent incarnation of the old machine was driven by a Raspberry Pi and a Mesa ethernet card.  The Mesa was connected almost directly to the limit and estop switches, and the step/dir lines went to a quad stepper driver board I got from Sparkfun a long long time ago.  The wiring was a horrible rat's nest of jumpers running between pin connectors glued upside down to a plank.  (I'm not exaggerating.) And I don't want to use the Sparkfun board again, for various reasons.

At some point I'm going to want to use the Mesa card with the new machine.  But what I'm picturing, that I don't have, is the "interface" board.  It needs to take 24V power, and have 3 or 4 of those little 16 bit stepper driver modules.  And it needs to have a bunch of screw terminal strips, set up to logically simplify the 6 or 7 pairs going to switches, the 3 or 4 connections to the motors, and all of the interconnect to the Mesa.  Basically what I want is an XYZ CNC router breakout board, with drivers.

But all I can find is complete controllers:  all of what I described, hardwired to an ATMega328, or ESP32.  Or, all of what I described, in the form of an Arduino hat.  Better, but still not very Mesa-friendly.

Can anyone point to the product I'm looking for?  Or tell me (nicely what I should be looking for instead?
 

 

 

Estop is the same way. With Estop, we are connecting a remora.input to LinuxCNC estop. Estop is a very subjective thing, and varies between setups. They can be complicated and require more hardware. Murphy has posted a simple example, and tux from a few pages back has posted a more detailed one.

Notice how the inputs are different on each of their different estops, which makes no difference because we are connecting remora.input.whatever to linuxcnc estop.

Tuxcnc is more complicated, He is using LinuxCNC components (not remora) to configure the estop logic. it includes a latching component, I assume he has one of those red buttons. Im not as knowledgeable with all the estop logic, as I live dangerously. The estop loop is a function of LinuxCNC and you need to connect it to remora in a way that suits your setup.

Sorry about that, I'll take a look tomorrow.

We have 3 phase power in houses, always, rated at 3x380V +-10% and can pull 16A at home from any plug, 32A in workshops/garages.
Lately the local provider started complaining if we pull over 15KW over long duration's, i do not blame them, we have 100A at our disposal.
To spite Americans (since i still refuse to go there despite being granted a Green Card 17 years ago), we can charge a Tesla at home with 22KW on any socket around the house, 60KW if we push it!
And that is with no permissions or requests or installing superchargers!

grijalvap wrote:

I understend what you mean but I want to keep the temporary tools because they are in the GCODE file, the operator don't has to select.
 

If you set the cut parameters up correctly (eg replicating sheetcam toolsets in qtplasmac by importing the Sheetcam tools), the user still won't need to select anything. Instead, Sheetcam will pass the tool number to QTplasmac in the gcode and it will retrieve the corrrect settings. Keep sheetcam the master of toolsets and update QTplasmac if you change settings.
 

 

here is a before and after

 


observe both configs. they are mostly the same, but some pins are different.

Pgain and ff1 and deadband are parts of the remora stepgen and used to tune motor control/feedback. feedback control has nothing to do with encoders or input from the motor. it is an internal math shit connected to the stepgen to tune motor position control like you would a servo.

regular stepgen and DMA stepgen have no difference in LinuxCNC. The same concept as inputs applies to the stepgen/dma stepgen. In the Config.txt you tell the MCU that pin P1_22 and P1_17 is step and direction of joint 0, which is remora.joint.0 which is connected to LinuxCNC joint.0

The DMA stepgen is a faster hardware based stepgen and requires dedicated hardware pins. LinuxCNC does not know if you are using DMA stepgen or regular stepgen and it does not care.

Looking at the EC500 DMA stepgen config, we can apply the same concept to the NVEM config.txt The config.txt for your specific board, and is just a way to tell the remora what pins do what. The default stepgen is regular stepgen because it is less to tune. If you want to change your stepgen to DMA stepgen, lets compare the config.txt DMA stepgen and apply it to the NVEM config.

 

If there are no hardware conflictions (there arent in this case) we can go about changing the stepgen to DMA stepgen. In this case the pins are the same for both boards. so replace your entire stepgen with the DMA stepgen and make sure the pins match the pins on your board