Advanced Search

Sorry for the delay, life got in the way.

Long story short test with a DVM were positive, could not test spindle due to the late hour.  At "m3 s25000" I am putting out between 9.98v and 9.99v, I hope the fluttering does not effect the Spindle performance.
 
I ended up with:
OUTPUT_SCALE = 12.27V/10V * 25000 = 30675

The issue is the power supply, currently I have one PSU that supplies both +-5v, +12v, the other PSU I have is 48v for Steppers.  the issue is you can only adjust the 5v side, the 12v is only "approximately 12v".

From the manufacture's documents:

Accurate voltage regulation is not guaranteed if the load does not draw the minimum current.

Looking at the block diagram the reason becomes clear: only Channel 1 (5V) is regulated via a feedback loop. Channel 2 (12V) is open loop and unregulated.So you have to adjust the 5V output with the potentiometer while your intended load is drawing its usual current... and you will get "approximately 12V" on the other output.Also the 12V output will fluctuate depending on current draw on the 5V output.

Of course you don't find these things out until you go digging.

The 12v side does fluctuate between 12.26v and 12.27v, I used the latter in your formula.

There may be a separate 12v PSU in my future, if I can make space in the controller box, which is currently packed.  Should have started with a bigger chassis, but I choose to use an old PC case.

Thanks for all the help, on to the next issue and I will have to test Spindle in daylight hours.


 

Here's the full text of the article for posterity and in case something happens with GitHub. I apologize for the formatting, I was fighting with the forum editor for a while and had to remove some links to get the post to submit:

Building a control system for a 500W Raycus fiber laser using LinuxCNC and QtPlasmaC

Introduction

This document describes a project at Madison, WI USA-based hackerspace Sector67 to create a control system for a Raycus 500 Watt fiber laser cutter using LinuxCNC and QtPlasmaC. This project was basically a proof of concept to work out what would be needed to operationalize a LinuxCNC-controlled fiber laser system. The laser source and head were donated to the space and came to us in an unproven state. There were several challenges that needed to be overcome, but in the end we were able to build a solidly functional fiber laser cutting system. 

Many thanks to the Sector67 members that contributed to this project, of course Chris Meyer but also Dave Franchino, Ken Delpapa and many others.

Also many thanks to the dedicated volunteers on the LinuxCNC forums who give of their time freely to foster not only an amazing open source project but also a fantastic open source community. In particular for this project Phillip Carter (phillc54), Tom Berisha (tommylight), Peter Wallace (PCW) and Rod Webster (rodw) were very helpful but there are many others. This project stands on the shoulders of those giants. A lot of this article is summarizing and re-hashing conversations that happened on the LinuxCNC forums.

It is important to mention that fiber lasers will absolutely make you blind in an instant. You must be extremely careful when experimenting with or operating a fiber laser. We surrounded ours with an enclosure and added two cameras to enable operator feedback without needing to put human eyes at risk. The information here is provided to capture our process. If you implement a fiber laser you are proceeding at your own risk and should educate yourself about the real risks of these devices.

 
The laser cutter

The hardware

The laser source

The laser source for this project was a 500 Watt Raycus C500 “Continuous Wave Fiber Laser”. This laser source has various methods of controlling laser power. For this project we are running it in “AD” mode supplying a 0-10V analog voltage for the laser power, a 24VDC for laser modulation, and 24VDC for laser enable. There is an RS232 serial connection on the device, but we were never able to get more than very rudimentary information from the serial connection. 

One important note is that if the LinuxCNC control system is sending a “laser enable” +24VDC signal when the laser source is powered up the laser source will enter a fault mode. In our configuration this signal is enabled when the “machine on” state is entered. We are currently resolving this by powering the laser source first and then enabling the machine. In QtPlasmaC this is the “POWER” button. The laser does send a +24VDC “laser ready” signal on the DB25 connector, and we could in theory use this to prevent entering the “machine on” state unless the laser is powered. However, we currently do a lot of machine testing without the laser on at all, so for now we are just manually working around this with awareness and the specific power on procedure.

The laser head

Our laser head is a “WSX-MN15” model. This manual focus laser head came to us with what should have been a standalone close-loop capacitive height sensor and control board. We could never get that to work properly, which was not a significant problem because from the beginning we wanted to get closed-loop height control controlled by LinuxCNC. So we ended up gutting the on-head capacitive sense and Z height controls and routing the new sensor (described below), home and float sensors, and Z stepper control back to the main control box.

One note is that in addition to everything we stripped off the head, we adapted the air assist to take a ¼” “push to connect” fitting. The threads on the head were G1/8 (BSPP) straight threads, not NPT. It is important to get that right or you may damage the threads on the head and not have an air tight fitting.

 
The laser head

The capacitive sensor
We used a BCL-AMP capacitive sensor for laser head height sensing. These capacitive sensors are typically used for height sensing in fiber laser cutting systems. The sensors come potted in an aluminum case with a small coax connector to connect to the laser head and a GX16 4-pin circular aviation connector to drive the device. These sensors look like this:

 
The capacitive amp

There are a number of capacitive sensors with this same basic form factor. We used a “BCL-AMP Amplifier Preamplifier Sensor For Friendess BCS100 Height Controller FSCUT1000 FSCUT2000 System” amp. As of the time this article was written, this amps is available for $52.50 US at www.aliexpress.us/item/3256804585924423.html.

Interfacing the amp to LinuxCNC is described in sections below.
The XY table
The table itself is not really notable. As a prototype platform it has a working area of about 2’x2’ with stepper motor control. It’s not especially fast or rigid unfortunately. There are plenty of other resources for how to get that working with LinuxCNC, so I won’t cover it in too much depth here.

Gas assist
We used a simple 24VDC gas solenoid to control the gas flow. We also implemented a low pressure bypass so that when gas is on there is always some amount of air flowing out of the laser head. This should hopefully prevent any contaminants from getting to the lens when the machine is running.

The electronics of the control system

Mesa card
We’re using a Mesa 7i92TF Anything I/O Ethernet card for I/O. We’re using the G540x2 firmware. We’re using three stepgens for XYZ, one encoder for capacitive sensor input, one PWMgen for 0-10V analog output, and a bunch of I/O. We’re using both the DB25 and 26 pin headers. One advantage of cards like the 7i92 is that you can select via jumper independently if you want the P1 or P2 to be pullup or pulldown. We set the P1 jumper to pulldown which simplified the startup state and the logic and wiring of some components.

Capacitive sensor interface
The functionality of the GX16 4-pin circular aviation connector on the amp seems to be one of the great mysteries of the Internet. As far as we have been able to find, no data sheet or manual for the amp exists, and the circuit diagrams provided by machine integrators do not provide enough detail to determine how to interface with the amp. As a result, we’ve had to reverse engineer the device to determine how to properly interface with it. The results of that experimentation have led us to the following pin functions, with the pins numbered per the GX16 connector spec:

Pin 1, +5V, DC5V DC supplied to the amp
Pin 2, Signal out, A ~5V variable frequency pulse train output
Pin 3, GND, 0V DC supplied to the amp
Pin 4, SHIELD, This is the one pin that you can find conclusively documented on the Internet. This pin should be tied to the cable shield. Internal to the amp, pins 3 and 4 are tied together to the ground plane, with pin 3 going through an RF choke inside the device.

With this hookup and some capacitive input on the small coax connector you can observe a variable-frequency output on pin 2 of the amp. The variable frequency output of the amp is unfortunately not a very clean signal. To clean up this signal we used a SN74HC14N schmitt trigger:

 
Schmitt trigger pinout

which creates a much cleaner square wave. VCC is wired to +5V and per the data sheet all of the inputs except for one are tied to ground so they don’t float. The output of pin 2 on the amp is wired to one of the trigger inputs, and the output of the trigger is wired to our Mesa 5i25 hostmot2 encoder A-phase input. The SN74HC14N also provides a modest level of signal isolation.

Capacitive frequency response
The following values were measured in a bench setup using a variable capacitor (a radio tuning capacitor wired directly to the amp inputs):

85pF, 2.50MHz
123pF, 2.00MHz
166pF, 1.67MHz
210pF, 1.54MHz
233pF, 1.44MHz

The response is not linear. The closer the metal is to the laser head (the higher the capacitance), the lower the frequency output is. When the head touches the material, the output frequency drops significantly.

0-10V laser power interface
For the 0-10V analog laser power signal we used a frequency to voltage converter from Amazon. This module provides 1-3KHZ 0-10V PWM conversion and basically worked seamlessly with the Mesa PWMgen. Some calibration using the on-board potentiometer was required, and it was not exactly linear, but close enough for our purposes.

 
The PWM to 0-10VDC converter board 

Laser modulation interface
Although we are using the laser source’s “AD” mode and sending power via a 0-10V analog signal, we wanted to keep the option to use a fast modulation signal if needed. For that we used a MOSFET board from Amazon that provided  0-20KHz PWM switching if we needed it. We are currently using it basically as a relay, but we wanted a very low delay when enabling the laser, and this board provides that.

 
The MOSFET board we used

The light tree
We had some scrapped equipment with a green/orange/red light tree.

We wanted to use that to make it clear when the laser was powered, when it could fire at any time, and when it was firing (or running a program at least). The light tree is powered by 24VDC. The green light is tied straight to the 24V power supply and lights any time the machine is powered on. The orange and red lights are controlled by a 5VDC relay board from Amazon pictured below.

 
The relay board we used

One advantage of this board is that each relay can be configured to be active high or active low by a jumper. We didn’t end up using this because one Mesa connector was configured to be pullup and one was configured to be pulldown and we could pick and choose our I/O. 

The laser enable signal
The laser enable signal is also 24VDC and controlled by one of the relays on the relay board.

Other I/O
We had other “standard CNC” I/O like home switches, estop, and a float switch. I won’t go into detail on those in this article as there are a lot of other places where those are discussed in depth.


The software configuration

LinuxCNC
We started with LinuxCNC 2.9.2 installed via live CD.

PNCConf
We used pncconf for nearly all of our configuration. We applied some configuration customizations after using pncconf. We automated these (described below) so that we could keep the ability to use pncconf to maintain and update the configuration when needed.

Post-pncconf fixes
We want to maintain the ability to update and regenerate the machine configuration using pncconf, but pncconf does not handle every type of customization. So we’ve created a shell script with the Linux sed tool to fix the generated configuration. That script includes “sed” commands (a Linux text manipulation tool) to do a few things:

* Fix a bug in the pncconf-generated config for an unmatched double quote in the loadrt hm2_eth command.
* Add a USER_COMMAND_FILE to the ini file. This file is later used to customize QtPlasmaC.
* As of LinuxCNC 2.9.2, pncconf does not enable setting the filter of the encoder, so we change the “hm2_7i92.0.encoder.00.filter 1” command in the main hal file to be “hm2_7i92.0.encoder.00.filter 0” for reasons described in the capacitive sensor section.

This script must be manually run each time after generating the machine configuration via pncconf.

Customizing QtPlasmaC preferences
Additionally, there are some QtPlasmaC preferences that are intended to be set interactively. Again in our pursuit of maintaining the ability to regenerate the configuration via pncconf we created a script to automate the customizations we want to be made in the . You can see the details of what is customized including the “Arc Voltage Offset”, “Arc Voltage Scale”, “Float Switch Travel”, “Use keyboard shortcuts” “Ohmic probe enable”, and “THC enable”
at github.com/Sector67/fiber-laser-control/...fix-plasmac-prefs.py. 

This script was implemented using the same “qtvcp.lib.preferences” ini file library that QtPlasmaC uses. This ensures the changes are made in a way that is consistent with QtPlasmaC, and requires that the script is run using python3. This script must also be run after a pncconf-based configuration is written.


Customizing QtPlasmaC labels and safe height
We additionally wanted to customize a QtPlasmaC label and the safe height. This required using some customization methods that are built into QtPlasmaC. Specifically, if a “qtplasmac_custom.py” file exists in the configuration directory it is processed. This allows customizing nearly all of the QtPlasmaC Python code. As of the writing of this article, we are just changing the “Arc” label. We may implement more customizations in the future.

We also wanted to be able to set a “Safe Height” lower than the default limit of 0.75”. This was slightly complicated since the default value of the “Safe Height” was being set after the qtplasmac_custom.py custom Python code is executed. So in order to set a custom Safe Height we need to use another customization method which requires specifying a “USER_COMMAND_FILE” file in the [DISPLAY] section of the main .ini file. We used “USER_COMMAND_FILE = qtplasmac_custom_post.py”.

Capacitive laser height sensing
Because the amplifier outputs a variable frequency signal, the output of the amp can be treated as an encoder input with the velocity representing the value of the signal. This makes it conceptually similar to a THCAD Mesa device. We are using a Mesa 5i25 board for high speed I/O, and so we can configure a hostmot2 encoder (linuxcnc.org/docs/html/man/man9/hostmot2.9.html#Encoder) via pncconf to read the amp output. Since we are only reading a pulse train and not a quadrature encoder this encoder needs to be in “counter-mode” so that each rising edge of the phase-A input is counted, and the value on phase-B is ignored. 

The relatively high frequencies output from the sensor (up to ~3MHz) create some special considerations for interfacing. The Mesa card’s FPGA is fast enough to read the signal, but for the fastest signals of the amps, the “filter” setting of the hostmot2 encoder should be set to “False” since 15 sample clocks at 25MHz is too long to successfully sample a ~3MHz signal. The filter documentation states:

(bit r/w) filter

If set to True (the default), the quadrature counter needs 15 sample clocks to register a change on any of the three input lines (any pulse shorter than this is rejected as noise). If set to False, the quadrature counter needs only 3 clocks to register a change. The default encoder sample clock runs at approximately 25 to 33 MHz but can be changed globally with the sample-frequency or muxed-sample-frequency pin.
The non-default (filter = false) 3 clocks should be fast enough, and with the schmitt trigger the signal is clean enough to work well with a three clock transition. Your custom.hal file will need something like the following:

setp    hm2_5i25.0.encoder.00.counter-mode 1
setp    hm2_5i25.0.encoder.00.filter 0

With this configuration in place, you can use Halscope or Halmeter to see the “velocity” response of the encoder change with the distance to the metal. The effective response range is around 0.5 inches, with good feedback in the first 0.1 inches off the material.

The output of the encoder velocity from a 0.1” Z move can be seen below:

 
A halscope image of the position and capacitive sensor input

We’ve scaled this value using a combination of the encoder scale and “Arc Voltage Offset” and “Arc Voltage Scale” PLASMA_PARAMETERS. You can see the specific changes in the earlier section on customizing the configuration, but by default the QtPlasmaC GUI does not allow voltage offsets higher than 5 digits, so we use the encoder scale to get the values into a range that can be scaled using PLASMA_PARAMETERS. This could be changed using the qtplasmac_custom_post.py method that we used to change Safe Height, but we already had this workaround in place prior to figuring out how to customize the Safe Height range.

This results in a ~50-100 range for "arc voltage" in the QtPlasmaC GUI and is sensitive enough to hold height well for the cuts that we do. We do customize the GUI to change “Arc” to “CAPACITIVE TORCH HEIGHT” via the qtplasmac_custom.py file. 

Fake ohmic probe and arc ok
Since the capacitive sensor output changes dramatically when it touches the part, we were able to implement a synthetic “ohmic probe” using custom hal:

# Make a fake Ohmic probe based on the capacitive sensor
# Use the .velocity-rpm so the .velocity can be left unused for arc_ok
loadrt comp count=1
addf comp.0 servo-thread
net fake-ohmic-probe-in hm2_7i92.0.encoder.00.velocity-rpm comp.0.in0
setp comp.0.in1 930000.0
net plasmac:ohmic-probe comp.0.out
# ohmic output is comp.0.out


We also implemented an “always on” arc ok signal:

# Fake "Arc OK" signal that is always true
loadrt not count=1
addf not.0 servo-thread
setp not.0.in FALSE
net plasmac:arc-ok-in not.0.out


Controlling laser power
The hardware board that converts PWM to 0-10VDC was interfaced to LinuxCNC with the following added to the custom.hal file:

# enable the spindle PWM to drive the laser power
net plasmac:torch-on hm2_7i92.0.pwmgen.00.enable 
setp hm2_7i92.0.pwmgen.00.scale 100
net laser-power spindle.0.speed-out-abs hm2_7i92.0.pwmgen.00.value

Additionally, the PWM frequency was configured to be 2000Hz via pncconf and you can see that value reflected in the laser_cutter.hal file:

setp    hm2_7i92.0.pwmgen.pwm_frequency 2000

Together these enable a 0-10VDC laser power signal. This will work well for cutting where we are not changing the power frequently. If we want to do raster-style engraving we’d need to switch to using something that does not pause motion when changed. To do that we’d need to switch to using something like M67 as outlined by tommylight at forum.linuxcnc.org/plasma-laser/51727-be...power-with-qtplasmac. 

GCode laser power injection
Since we are controlling laser power with spindle speed 0-100 and using the materials “cut amps” to specify the power level for that material, we also need to modify each “M3 $0 S1” line to utilize the material’s cut_amps. The line needs to end up looking like

M03 $0 S#<_hal[qtplasmac.cut_amps-s]>

We achieved this by creating a custom_filter.py that you can see at github.com/Sector67/fiber-laser-control/...fig/custom_filter.py. This has generally worked OK for us so far but might need some refinement as we use different post processors.

Controlling the light tree
The green light of the light tree is simply wired to the +24VDC supply and indicates the machine is powered.
The orange light is intended to indicate that the laser could fire at any time. It is controlled by the following custom hal:

# enable the orange light to represent when the machine is enabled
# and the "torch on" is enabled.
net plasmac:torch-enable and2.0.in0
net machine-is-on and2.0.in1
net orange-light and2.0.out

We sometimes run a program without the torch on to test things, and so it is convenient to see at a glance that the laser will not fire even if the program is started.

The red light indicates that a program is running. If the orange and red lights are both lit then laser may fire at any time. The red light is controlled by the following custom hal:

net plasmac:program-is-running and2.1.in0
net halui-mode-is-auto and2.1.in1
net program-running and2.1.out

net program-running or2.1.in0
net plasmac:program-is-paused or2.1.in1
net program-running-or-paused or2.1.out

…

# enable the red light to represent when the laser is "firing"
# currently defined as when a program is running or the torch is firing

net program-running-or-paused or2.0.in1
net plasmac:torch-on or2.0.in0
net red-light or2.0.out

You can see the full custom.hal file at github.com/Sector67/fiber-laser-control/...in/config/custom.hal. 

Gas assist
We are currently using compressed air exclusively, and have implemented a solenoid valve to turn on when a program is running and turn off shortly after. The gas assist is controlled by the following custom hal:

net plasmac:program-is-running and2.1.in0
net halui-mode-is-auto and2.1.in1
net program-running and2.1.out

…

# for now a very naive gas-solenoid control
loadrt timedelay
addf timedelay.0 servo-thread
net program-running timedelay.0.in
setp timedelay.0.on-delay 0.0
setp timedelay.0.off-delay 1.0
net gas-solenoid timedelay.0.out

The gas uses the timedelay component to run for a second after the program ends. This is probably not needed but we’ve left it in place. This timing seems to work well enough as the initial probe takes more than enough time for the gas to get started. If we wanted to turn the torch on and off during a program, we could potentially modify the “arc ok” signal to wait a second for gas to flow before turning the laser on. This would slow things down a bit but if we ever used a gas other than compressed air we may want to conserve it.


The cameras
We wanted to set up a couple of USB cameras to watch the whole table and the laser head itself. We used a cheap endoscope camera for the laser head. We were using a pretty old PC and ran into USB throughput issues, but were able to get small videos for both cameras with the following scripts:

ffplay -i /dev/video0 -x 320 -y 240 -an -window_title "lens camera" -left 1400 -top 100 -video_size 320x240

and

ffplay -i /dev/video2 -x 320 -y 240 -an -window_title "machine camera" -left 1400 -top 400 -video_size 320x240

If you have a more modern PC you could probably run larger video streams. We were then able to run the Linux “SimpleScreenRecorder” tool to capture videos of the whole screen including video streams. 


Results and next steps
With this configuration in place we’ve made basic cuts in stainless and mild steel. We still have a bunch of experimentation and tuning to do. The machine cuts 1mm stainless sheet very well, leaving a small burr around the part. We’ve cut up to 0.1” mild steel and expect to be able to cut at least 0.125” with this setup. Our table could be more rigid, so we do currently get some resonance.

You can see one of our very first videos at: , and another video of the laser cutting 1mm stainless steel: .

Utilitas wrote:

I also did some more digging and found the usdigital website again. (I had stumbled upon it much earlier while I was
looking at steppers a couple weeks ago, then forgot what their website was) They also have a somewhat modular
system of encoders but of an "optical" type. They are notably more expensive, but do represent another potential
option in the US.
 

And for my next point of reference, I'm using US Digital encoders for both my mill spindle motor and lathe high-res spindle encoder.

The mill encoder is a 4096 ppr and runs up to 8k RPM.
Lathe encoder is a 10000 ppr and runs up to 3500 RPM.

Both encoders are differential line driver outputs.  The mill encoder is an E6 mounted on the motor, and the lathe is an S6 model belt driven from the spindle.

I did have to turn the input filter off on the 7i96s for the high-res encoder as it was a little flakey near the upper end of the RPM range with the filter on.

Very pleased with both encoders.  TBH, I probably would have used a US Digital (instead of the AMT) on my lathe motor had I known about them at the time, but the CUI is working fine in this application and it's rather less expensive.

As a point of reference, I'm using the CUI/AMT 31 (capacitive) commutation encoder on my lathe spindle servo.  Mine is a differential output, and the signal is going to a Copley XSL drive.  CUI shielded cable.

No (obvious) issues at 170khz (2048ppr @5kRPM)

EDIT
Note that I'm also using a fairly high res optical encoder directly on the spindle for positioning.  I wouldn't trust the CUI for really accurate positioning of a rotary axis unless there's a huge reduction... but it's working fine with the servo in velocity mode since LCNC manages the position via the 10k pp/r optical.

Edit:  Never mind,  I wasn't able to delete this post but I just found one of the cables on ebay its called a AMT-17C-1-036 - AMT ENCODER CABLE 17CONDUCTOR will be here in a few days.

Hey how's it going spumco.  So I've had the opportunity to receive a few items in the mail of which include:  A Mesa 7i96s control board, a U3K driver, and an AMT312Q CUI encoder.  With the board I've had the chance to mess around and have it spinning a stepper and have an input pin receiving a limit switch signal, so all is dandy there so far.  Both the U3K and the encoder I received in the mail just a few hours ago so haven't had the chance to energize U3K or anything yet (It was used but I trust the seller).  But with the encoder I thought that I was just going to be able to use some leftover JAE molex looking crimped ended wires and insert them into the connector housing then solder them onto a length of cat5 or an old usb cable and make a wire harness that would reach to the back of the cabinet.  That turned out to not be the case.  The CUI encoder uses some strange end-crimps because all the ones I have won’t fit into the connector housing.  I was going to buy the cable and actually they should have included one with the encoder but it appears they are trying to milk peoples wallets by charging almost as much for the special cable as they do for the encoder alone.  Do you know what those end crimps are called that goto those encoders?  It doesn’t say anywhere what they are other than JAE connector of some kind?  I’m thinking of buying one of the AMT One Touch Zero modules and just steeling the cable off of it after zeroing the encoder.  Pluss the module has a nice molex connector on it already and I’m pretty good at crimping Molex.  What would you recommend I do?  Thanks

Thanks a lot. initial bracket was copy-paste mistake. but that comma was problem.

At last stepper is spinning. Had problem with limit switches so added invert = true in config.txt.

But still to be used on machine I had to make many changes.

1. How to add probe? PC_5 pin.
2. Estop to PF_3
3 Spindle to PB_7 (I want PWM output on PB_7)
(Cheap chinese spindle, No Spindle Start or direction only PWM)
PWM 0 is Stop PWM 255 is Full RPM)
4. Last but not least, nice GUI
strugling with qtdragon.
5. user_command file xxxxxx_800.py is giving errors. so I commented out in ini file.

I am still stuck and going round in circles.

I have flashed an RT1052 based NVEM (Marked V5) with the remora-rt1052-3.1.2.bin firmware and uploaded the nvem-rt1052.txt config file to it (minus the NVMPG component).

On boot the debug port shows:

Initializing PHY...

## Entering SETUP state


1. Loading JSON configuration file from Flash memory



2. Parsing JSON configuration file
Config deserialisation - Deserialization succeeded

3. Board Type: NVEM

4. Configuring threads
Creating timer ISR thread 40000
Creating timer ISR thread 1000
Creating DMA thread 500000

5. Loading modules

Creating a std module
Creating an Ethernet communication monitoring module
Creating Pin @
port = GPIO3
pin = 0

Base thread object

X - Joint 0 step generator

Creating a std module
Creating Pin @
port = GPIO1
pin = 22
Creating Pin @
port = GPIO1
pin = 17

Base thread object

Y - Joint 1 step generator

Creating a std module
Creating Pin @
port = GPIO1
pin = 24
Creating Pin @
port = GPIO1
pin = 31

Base thread object

Z - Joint 2 step generator

Creating a std module
Creating Pin @
port = GPIO1
pin = 18
Creating Pin @
port = GPIO1
pin = 25

Base thread object

A - Joint 3 step generator

Creating a std module
Creating Pin @
port = GPIO1
pin = 27
Creating Pin @
port = GPIO1
pin = 21

Base thread object

B - Joint 4 step generator

Creating a std module
Creating Pin @
port = GPIO1
pin = 16
Creating Pin @
port = GPIO1
pin = 23

Base thread object

C - Joint 5 step generator

Creating a std module
Creating Pin @
port = GPIO1
pin = 20
Creating Pin @
port = GPIO1
pin = 19

Servo thread object

FHA
Make Digital Input at pin P3_26

Creating a std module
Creating Pin @
port = GPIO3
pin = 26

Servo thread object

FHB
Make Digital Input at pin P4_30

Creating a std module
Creating Pin @
port = GPIO4
pin = 30

Servo thread object

SRO
Make Digital Input at pin P3_19

Creating a std module
Creating Pin @
port = GPIO3
pin = 19

Servo thread object

SRJ
Make Digital Input at pin P4_20

Creating a std module
Creating Pin @
port = GPIO4
pin = 20

Servo thread object

IN01
Make Digital Input at pin P4_26

Creating a std module
Creating Pin @
port = GPIO4
pin = 26

Servo thread object

IN02
Make Digital Input at pin P4_27

Creating a std module
Creating Pin @
port = GPIO4
pin = 27

Servo thread object

IN03
Make Digital Input at pin P4_21

Creating a std module
Creating Pin @
port = GPIO4
pin = 21

Servo thread object

IN04
Make Digital Input at pin P4_24

Creating a std module
Creating Pin @
port = GPIO4
pin = 24

Servo thread object

IN05
Make Digital Input at pin P4_28

Creating a std module
Creating Pin @
port = GPIO4
pin = 28

Servo thread object

IN06
Make Digital Input at pin P4_25

Creating a std module
Creating Pin @
port = GPIO4
pin = 25

Servo thread object

IN07
Make Digital Input at pin P4_29

Creating a std module
Creating Pin @
port = GPIO4
pin = 29

Servo thread object

IN08
Make Digital Input at pin P4_23

Creating a std module
Creating Pin @
port = GPIO4
pin = 23

Servo thread object

IN09
Make Digital Input at pin P4_31

Creating a std module
Creating Pin @
port = GPIO4
pin = 31

Servo thread object

IN10
Make Digital Input at pin P3_18

Creating a std module
Creating Pin @
port = GPIO3
pin = 18

Servo thread object

IN11
Make Digital Input at pin P3_21

Creating a std module
Creating Pin @
port = GPIO3
pin = 21

Servo thread object

IN12
Make Digital Input at pin P3_20

Creating a std module
Creating Pin @
port = GPIO3
pin = 20

Servo thread object

CIN
Make Digital Input at pin P4_18

Creating a std module
Creating Pin @
port = GPIO4
pin = 18

Servo thread object

XIN
Make Digital Input at pin P4_17

Creating a std module
Creating Pin @
port = GPIO4
pin = 17

Servo thread object

YIN
Make Digital Input at pin P4_16

Creating a std module
Creating Pin @
port = GPIO4
pin = 16

Servo thread object

ZIN
Make Digital Input at pin P4_15

Creating a std module
Creating Pin @
port = GPIO4
pin = 15

Servo thread object

AIN
Make Digital Input at pin P4_14

Creating a std module
Creating Pin @
port = GPIO4
pin = 14

Servo thread object

X100IN
Make Digital Input at pin P4_13

Creating a std module
Creating Pin @
port = GPIO4
pin = 13

Servo thread object

X10IN
Make Digital Input at pin P4_12

Creating a std module
Creating Pin @
port = GPIO4
pin = 12

Servo thread object

EP
Make Digital Input at pin P4_11

Creating a std module
Creating Pin @
port = GPIO4
pin = 11

Servo thread object

INDEX
Make Digital Input at pin P3_22

Creating a std module
Creating Pin @
port = GPIO3
pin = 22

Servo thread object

WHA
Make Digital Input at pin P3_16

Creating a std module
Creating Pin @
port = GPIO3
pin = 16

Servo thread object

WHB
Make Digital Input at pin P3_17

Creating a std module
Creating Pin @
port = GPIO3
pin = 17

Servo thread object

OT01
Make Digital Output at pin P4_01

Creating a std module
Creating Pin @
port = GPIO4
pin = 1

Servo thread object

OT02
Make Digital Output at pin P4_02

Creating a std module
Creating Pin @
port = GPIO4
pin = 2

Servo thread object

OT03
Make Digital Output at pin P4_03

Creating a std module
Creating Pin @
port = GPIO4
pin = 3

Servo thread object

OT04
Make Digital Output at pin P4_04

Creating a std module
Creating Pin @
port = GPIO4
pin = 4

Servo thread object

OT05
Make Digital Output at pin P4_05

Creating a std module
Creating Pin @
port = GPIO4
pin = 5

Servo thread object

OT06
Make Digital Output at pin P4_06

Creating a std module
Creating Pin @
port = GPIO4
pin = 6

Servo thread object

OT07
Make Digital Output at pin P4_07

Creating a std module
Creating Pin @
port = GPIO4
pin = 7

Servo thread object

OT08
Make Digital Output at pin P4_08

Creating a std module
Creating Pin @
port = GPIO4
pin = 8

Servo thread object

OT09
Make Digital Output at pin P4_09

Creating a std module
Creating Pin @
port = GPIO4
pin = 9

Servo thread object

OT10
Make Digital Output at pin P4_10

Creating a std module
Creating Pin @
port = GPIO4
pin = 10

Servo thread object

Spindle PWM

Creating a std module

## Entering START state

Starting the BASE thread
Registering interrupt for interrupt number = 100
configuring Timer 1
timer started

Starting the SERVO thread
Registering interrupt for interrupt number = 101
configuring Timer 2
timer started

## Entering IDLE state

I install the remora-eth-3.0.c component and can start Linuxcnc using the  remora-rt1052-basic profile (having changed the hal file to use remora-eth3.0 module rather than the (old?) remora-nv module).

I can then connect linuxcnc to the NVEM and one of the LED's on the NVEM board turns on or off depending on if I enable or disable linuxcnc.

But when I try to move the x or y stepper nothing happens. Also if I view the remora.inputs I do not see any changes in response to pulling the inputs to gnd.  If I look at the remora.status using the hal viewer it shows the board as connected. If I look at the remora counters using the HAL viewer I can see them incrementing.

So on the face of it it looks like the board is connected but not actually doing anything.

So what have I missed?

Note: I am assuming the remora.inputs should be updated in the hal viewer even if the hal file was wrong.

 

I am running a 600w servo with t3d servo driver, servo is rated at 3000rpm, jogging from the driver it did 3500 with ease. Running it from linuxcnc it stops at 480rpm.
I am using a raspberry pi 5 with a cheap chinese 5axis BOB, got my steppers and limitswitches working as they should, but setting up the servo has me stumped. Servo is set up in velocity mode in hal. For some reason stepgen is limited to 8000steps a second, the servo has 1000 steps pr rotation. Servo does the commanded speed perfect up to 480 but I cant get it to go faster and cant find where the limits on the stepgen is. I have tried to change steplen, stepspace, dirhold, dirsetup velocity and scale, scale affects the motor speed up to 480 but there it stops, I cant see any difference in the other settings.
If I enable maxvel in hal i get an error message saying stepgen is limited to 8000steps pr second. Is there any way I can change this?   

Hi PCW thanks for your trying to help. Im not sure what breakout board it is other than the one that came stock with a Syil machine. I took a couple photos of it and picture of the stepper drives. I also included uploaded the ini and hal files. Do you think i should get rid of the generic breakout board and replace it with something more modern?

Hello,All my issues are resolved. The spindle is running, and the end stops and stepper motors are also functioning. For those looking for an example, I have attached the files.
 
 
   
 

disneysw wrote:

I have read the full thread, wiki and looked at git hub and there are a number of things I am still confused about due to conflicting information.

I am using a standard LinuxCNC distro on an i5 PC. I have erased and programmed an NVEM V5 board (RT1052) using pyocd and the remora-rt1052-NVEM-0.2.1.bin and the board responds to pings at 10.10.10.10.

I cannot upload a config to the remora board due to time outs, but I understand this is to be expected as the firmware has a full config built-in - is this correct or is this the root cause of my issues?

The board outputs the following via the debug port on boot:

        Initializing PHY...

         ## Entering SETUP state


         ## Entering START state

          Starting the threads

         ## Entering IDLE state

I have installed the remora components (remora-eth, remora-nv, remora-nvmpg) into LinuxCNC and I copied various remora configs to my config directory.

Satrting LinuxCNC and using the remova-nv config I can get the x & y steppers to sort of move but I cannot see any inputs change state (I have tried all of them). In the HAL viewer I can see the Remora status as OK and both the servo-thread.time /remora.update-frq.time are updating.

Ultimately I want to set this up for a lathe with x,y and spindle control but for now it is sitting on my desk with two steppers and some switches wired up to the inputs.


So my questions are:

1: have I flashed the correct firmware?
2: do I need to upload a config file to the NVEM - if so why would I get a timeout (this is mentioned by someone else in an earlier post)?
3: If the above is OK why can I not see any input changes?
4: Do anyone have a Lathe config as a starting point?

Thanks in advance

The default config within the firmware has only three step generators configured. You will need to upload a config, but strange you are getting timeouts..

Barely can hear it over the spindle/endmill noise, but for sure it is there, steppers skipping, and from that faint sound seems like underpowered a lot, so what current are the drives set to?
And what microstepping are they set?

Hi 
Some time ago I've upgraded my 3040. I've replaced all electronics and now I'm using hy-jk02-m bob + 4xTB6600. Stepper motors are still original Anchuan 57hd0401 1.8deg 2A.I've also upgraded spindle to 2.2kw driven by hy inverter. Only one Power supply for motors is 24v 20A. Currently I've got an issue with Y axis. I've tried to cut different size of squares in plywood. Everything went OK, after measuring difference was that small so I can take it as a measure error. In one of the tests I've cut 30x30 square and then I've tried to cut it diagonally. Unfortunately I've noticed shift during cutting in X+Y - direction. Because of that axis is shifted. I'm not sure what's is wrong. Mechanically I cannot see any issue with coupler or driving nut. I made a video from this test. Please have a look here :





Efect in attachment 
 

I have read the full thread, wiki and looked at git hub and there are a number of things I am still confused about due to conflicting information.

I am using a standard LinuxCNC distro on an i5 PC. I have erased and programmed an NVEM V5 board (RT1052) using pyocd and the remora-rt1052-NVEM-0.2.1.bin and the board responds to pings at 10.10.10.10.

I cannot upload a config to the remora board due to time outs, but I understand this is to be expected as the firmware has a full config built-in - is this correct or is this the root cause of my issues?

The board outputs the following via the debug port on boot:

        Initializing PHY...

         ## Entering SETUP state


         ## Entering START state

          Starting the threads

         ## Entering IDLE state

I have installed the remora components (remora-eth, remora-nv, remora-nvmpg) into LinuxCNC and I copied various remora configs to my config directory.

Satrting LinuxCNC and using the remova-nv config I can get the x & y steppers to sort of move but I cannot see any inputs change state (I have tried all of them). In the HAL viewer I can see the Remora status as OK and both the servo-thread.time /remora.update-frq.time are updating.

Ultimately I want to set this up for a lathe with x,y and spindle control but for now it is sitting on my desk with two steppers and some switches wired up to the inputs.


So my questions are:

1: have I flashed the correct firmware?
2: do I need to upload a config file to the NVEM - if so why would I get a timeout (this is mentioned by someone else in an earlier post)?
3: If the above is OK why can I not see any input changes?
4: Do anyone have a Lathe config as a starting point?

Thanks in advance

Hello,My setup for a re-retrofit (from Mach3 to LinuxCNC) of an old EMCO Compact 5 CNC lathe is as follows:

• RPI 5 with Linuxcnc 2.9.2 on Debian bookworm
• Mesa 7i96s
• 2x 200W AC servos with A5 drives from Lichuan, for X and Z. Encoders are 17bit incremental type (why on earth did I not get the absolute ones when they were like 20 dollars more....)
• 1x 1000W AC servo with A5 drive from Lichuan, for spindle. Same encoder as for the 200W motors.
  
  As far as I've understood, normal lathe use would indicate that i run the axis drives in position mode with step/dir inputs, and the spindle drive in speed mode, with -10- 10V analog input.
  
  I believe that is what will be relevant info for the questions in this thread?  
  
  1. In the axis section of the pncconf wizard I am faced with some settings I have never encountered before, namely "step-on time", "space", "direction hold" and "direction setup". I have tried to read up on what they mean and how it relates to the information I am given in the servo drive manual. Among the numerous settings and points of information for the servo drives, I cannot find anything which is called the same or remotely the same as those parameters. Can I assume that my step high/low and pulse high/low times are identical, and that I can simply use the drives' maximum step frequency as a base for step-on time and space? It is stated as 1MHz in the manual. What about direction hold and direction setup, could someone please explain what they are? I am anxious of doing something bad to my new precious drivers and motors, so in case any wrong settings can hurt my drives, i just want to be on the safe side...
  2. Is there anything else I need to pay special attention to when using AC servos with step/dir inputs, instead of stepper motors? I see there are some unseleactable/uneditable tuning parameters (PID info) on the left; I thought I would be tuning the servos internally on the drives?
     
     Link to servo motor with drive (200W version): 
     www.aliexpress.com/item/1005005440028771...ain.5.76c81802WfkwiM