Advanced Search

In other news, my new pc build runs much better generally and I don't have the real-time delay error warnings anymore. And I've been busy making mechanical progress on my machine.  

youtube.com/shorts/gAclUIYUk1Y?si=PEWtBkNokJtn4JyQ

I've been messing with this again. I have an intel 2 ports pcie lan card that I tried to use. I got the ip address from ip a command and put it in the etc/ethercat.config. for some reason only the lan on the motherboard works even with the address changed. But the servos were crunchy sounding and it was disconnecting randomly. I put it back to the correct address for the motherboard port and its smooth. I have not been able to run ethercats on the pci card.

Got the saw back home. She's definitely rough. Good news is it looks possible to make the saw miter in the opposite direction by removing one support bar. The way the shuttle seems to work is it has a ball screw with a limit switch on it to control the length that the hydraulic retracts. Once it hits the limit switch it stops the hydraulic from further feeding forward. I may rework the vices as they currently have a very shallow depth of hydraulic travel. The bearings in the saw wheels feel sloppy but smooth. In the morning I am pressure washing the whole machine and may try to put power to it to see if anything still works. If I can reuse hydraulic pump and band saw motor that would be awesome!

Hi all,

JCLPCB delivered my self made PCB board. Testing ongoing. I had to order 5 boards. If anyone is interested in one, I have a few spares. Located in the Florida USA. 

 

I'm having a weird issue with my programs, or maybe my setup when I generate the NC codes. For some reason, my program "starts" (G54 setting the origin) way outside of the boundary of my machine. You can see in the picture the "G54" is way out there. The default program ("LinuxCNC") puts the G54 right on the limits of the machine (at least per the drawings). Please see the attached screenshots. What could be causing this? I'm generating GCodes from Fusion 360.Thank you! 

yeah there are some file managers you can integrate into axis tab and use the way you describe. There are some TK alternatives file browsers I have yet to figure out how to use yet

well, maybe you dont need to use the preassigned index, you will find out i guess

i dont think you are connecting your spindle pins correctly thought. its waiting for the index enable probably
compare to this one
github.com/cakeslob/RRW_LAB/blob/inc/Lin.../remora-xyz.hal#L128

can you please elaborate on copying the files over? I moved private_data.py over but wasnt able to move the pncconf.py to the pncconf folder

Hi everyone,
I seek help in commissioning a Motor with a Beckhoff Ax5000 series drive within TwinCAT to then transfer that tested setup to linuxcnc-ethercat. I cannot for the life of me get that motor to run over.
Setup:
Motor: HarmonicDrive LynxDrive-20C-100-MEE-AO (reduction 100, MEE Encoder (Heidenhain EQN-1125 Endat 2.2/2.1), motor values are known, commutation unknown)
Driver: Beckhoff AX5206-0000-0203 Fw 1.06
Goal: Be bale to move the drive from NC in Twincat to check for functionality of the setup
What did I try:
- Scan Bus in TwinCat to find devices
- Found the Driver
- Setup of power management, safety (off), set mode for channel 1 to position control
- Setup Channel 1: X11 for encoder connector, selected Heidenhain EQN1125 from list, manually setup the motor with relevant values (pdf: harmonicdrive.de/fileadmin/user_upload/E...8856_08_2018_V04.pdf, page 17)
    When I try to scan for the encoder it identifies as Endat 2.2 without a nameplate. However, when selecting an Endat2.2 from the list of encoders, it does not work. (0xF148: Build drive system: unknown feedback system)
    Question: I assumed that this table takes the values for the motor and not for the output shaft (which is behind the harmonic drive's reduction), correct?
- Setup of scaling
     Question:  Here I am not sure. To me it makes the most sense to set this up for the motor shaft (as this is where the encoder is). I.e. 360°/motor revolution (see screenshot) - correct?
 
Next would be to setup the commutation setup (mechanical and electrical offset).
This is where I struggle.  The manual (www.beckhoff.com/en-en/download/61857533) states two different chapters regarding commutation:

1) Chapter 9.1.4 Third-party Motors
Step one asks to ensure motor rotation: The output shaft is connected to the HD. Given a reduction of 100 it is really difficult to backdrive the thing. Question: Am I correct in assuming that the HD reverses the direction of rotation? that is: if the servo motor moves CW, the output moves CCW?
Next step is the electrical commutation offset determination.
I tried to follow page 168ff using P-0-0166:
I get values after starting the command, with equal directions being "No". Changing U and V accordingly changes direction of the motor, but has no effect. I cannot get a constant value. I keep chasing my tail around.
Note: At this point P-0-0150 Commutation Node is set to 3; Adjustable commutation offset (mechanical) is 0 deg

I then followed chapter
Manual 9.6 list commutation methods (p 201ff)
Accordinglx, P-0-0160 is executed first
Regardless of the actual value of P-0-00578 (Electrical commutation offset) I get a value for the mechanical commutation offset which I enter in P-0-0150 above.
Doing so, an flipping the polarity of UV, I then get the following result for P-0-0166: Equal Directions: yes; Offset: 357.55 deg
 
I do not understand what way is the correct way. Accordingly, I am not sure if the offset is correct.
Now I undertand I should be able to move th eaxis using NC-A: Online (image 3)
 
I can enable the drive and it does start to make light noises and one can feel light vibration on the output shaft.
However, when I send a command using F2/F3 I get an increase in following error and nothing moves. (Image 4).
 
Parameters of the axis enc are as indicated by image 5.
 
I assume something in scaling is borked and thus the PID cant work properly. But I cannot find anything that is missing.

- I have checked (to the best of my ability) the polarity and pins for both the power and the encoder connector. At this point I assume that these are correct.
- I have manually pulsed the motor with a low dc voltage, It then performs the expected jump. The encoder provides a new value afterwards as well.
I am open for any and all advice. It must be sooo close.
Thank you!
 

I think your motor encoder feedback needs to go into your motor driver while the glass scale quadrature signals into linux CNC PID module.

Looks OK

You can also simply delete the num_xxxx=n stanzas in the hal file
and all hardware in a particular configuration will be enabled.

Hello PCW,
I managed to get rid of the error messages by changing these values in the hal file:
num-pwmgens = 2 (from 1) and
num-stepgens = 4 (from 5)

Now I also can see pwmgen.01 in the halcmd show all *pwmgen*:

roland@linuxCNC:~$ halcmd show all *pwmgen*
Loaded HAL Components:
ID Type Name PID State

Component Pins:
Owner Type Dir Value Name
36 bit IN FALSE hm2_7i96s.0.pwmgen.00.enable <== spindle-enable
36 float IN 0 hm2_7i96s.0.pwmgen.00.value <== spindle-vel-cmd-rpm
36 bit IN FALSE hm2_7i96s.0.pwmgen.01.enable
36 float IN 0 hm2_7i96s.0.pwmgen.01.value

Pin Aliases:
Alias Original Name

Signals:
Type Value Name (linked to)

Parameters:
Owner Type Dir Value Name
36 bit RW FALSE hm2_7i96s.0.pwmgen.00.offset-mode
36 s32 RW 1 hm2_7i96s.0.pwmgen.00.output-type
36 float RW 18000 hm2_7i96s.0.pwmgen.00.scale
36 bit RW FALSE hm2_7i96s.0.pwmgen.01.offset-mode
36 bit RW TRUE hm2_7i96s.0.pwmgen.01.out0.invert_output
36 bit RW FALSE hm2_7i96s.0.pwmgen.01.out0.is_opendrain
36 s32 RW 1 hm2_7i96s.0.pwmgen.01.output-type
36 float RW 5000 hm2_7i96s.0.pwmgen.01.scale
36 u32 RW 0x005B8D80 hm2_7i96s.0.pwmgen.pdm_frequency
36 u32 RW 0x00004E20 hm2_7i96s.0.pwmgen.pwm_frequency

Parameter Aliases:
Alias Original Name
hm2_7i96s.0.pwmgen.01.out0.invert_output hm2_7i96s.0.gpio.025.invert_output
hm2_7i96s.0.pwmgen.01.out0.is_opendrain hm2_7i96s.0.gpio.025.is_opendrain


is this correct ?
Tahnks a lot and good night

Alright, I'm getting really close now (I think), but I'm to a point where I'm not 100% sure what the deal is. Unfortunately, the pin I needed to use for the QEI encoder module happens to be a bad pin on my SKR 1.4 Turbo apparently. I can't get it to pull high. I may have messed it up years ago trying to get neopixel LEDs working, I don't know. I set up a new pin as a digital input on the Y limit connector (Pin 1.28) and simply mapped the index pulse to that pin in my hal file. I'm seeing what appears to be a solid pulse in halscope. I'm also seeing it trigger on the phaseZ and index-enable pins. However, every time trying to do a threading operation, my program hangs at what appears to be waiting on the index pulse. I know the documentation states that the pins are pre-assigned and can't be changed, but I figured the index was handled differently since it included the remora.input.N is mapped in hal, but maybe something on the backend with the way the QEI encoder is handled. I apologize in advance if my HAL and INI look messy but everything else seems to work. I had to set my servo thread to 2000000 to get around the unexpected real-time delay error, but my latency in histogram --nobase seems great with isolcpus 1,2,3 on the Pi 4. I did try running the program with the servo period set to 1000000 in my INI just to see if that had something to do with a timing issue when registering the index-enable true when Linuxcnc expects to see it, but, it didn't work. Just about everything else seems to be working. Anyways here's my HAL again, my INI, and my config.txt

Did you enable 2 PWMGens in the hal file?

Success.  I went with LMDE6 and the install went much smoother.  Upgraded to 2.10 and can run a qtplasmac sim.