Advanced Search

Sounds great!
What are your plans with this?
Keep it separate in your code or bring it into mainstream linuxcnc code?

As promised - here is a little update.

Now evrything is running or better starting. The Beckhoff modules do what they should do, 2 oft the servos can be jogged but 1 servo is not able to be jogged and when trying to an amplifier error ist displayed in a pop up display. The motors are not yet tuned as they are no yet mounted to the machine.

I can`t really understand the difference of behaviour as all of the 3 servos are out of the box without any change to the values.

The only thing inside lcnc wich is possibly related to it is the ferror value - nothing else.

What could be a good starting point to figure out what goes wrong?

- If helpful for anybody I could post my setup files

Please excuse me, I didn't think about that at all, of course I'm happy to do it that way and thank you very much always

I knew it had to be something simple I was overlooking. I'll give this a try. Thanks for the explanation.

You can do almost anything you like very easy with Flex GUI. Trying to modify built in GUI's is very difficult due to how complex they are and in the case of Axis the code is almost impossible to read.

gnipsel.com/linuxcnc/flexgui/index.html

JT

Thanks everyone. I'll give the resistor a try even though the unit fails the manufacturers test. If that doesn't work I'll use a reed relay until I fix or sell it.

Hi all.

In the previous post i designed a c coded cia402 component to use with external homing, running on a general ethercat .xml config.

In this post i can announce that i included a new driver into the lcec source code.
The delta-asda-b3 is now included. And it can use external homing using homemod_extern.so
The homemod_extern is specified in the .ini file : link

Now the hal file, looks quite simple :
hal example
And also the ethercat .xml file look simple :
ethercat-conf example

Source:  
linuxcnc-etthercat
homemod_extern

I'm using 24V on the Mesa. I tested the relay according to the service manual with a multimeter set to continuity and the contacts do not close even though the "ok to move" LED is lit on the inverter board indicating the relay should be closed.  Thermal Dynamics support says no wetting resistor is required and the data sheet for the Axicom V23079-A1005-B301 relay says 10mA @ .2V for minimum.  At some point, when I have time, I will attempt to replace the relay...unfortunately you have to completely disassemble the unit to get at it.  I will try putting a resistor across it just in case.Thanks to everyone for their help. 

You have set your limits to:
Try inverting your limits in [AXIS_Z] and [JOINT_1] sections:

Afternoon,
I'm having a bit of trouble compiling a custom firmware for a new 7i92TF. What I'm after is a config for a G540 on P1 and a Mesa 7i76U on P2 (or vice versa really, not fussed). I have been attempting to build a custom firmware that fits this config, but cannot get the Field I/O via SmartSerial to resolve correctly.

Where I'm at:

1. Have the latest source+fimware from Mesa (www.mesanet.com/software/parallel/7i92t.zip)
2. 7i92T connected to a machine w/ new install of LinuxCNC (2.9.4 + all apt updates),
    - 7i76U on P2, +5v from the parent card and 12v applied to the field power.
    - mesaflash connects to 7i92T, write the supplied 7i92t_7i76x2d.bin firmware and reload
    - get the SmartSerial info w/ mesaflash ... --sserial, finds the 7i76: ...7I76 GPIO+SPINDLE (unit 0x1000E070)..
    - check w/ hal: can load the hostmot2 driver, connect to the 7i92T, ss finds 7i76, test I/O, can detect inputs high/low
    - hardware thus seems to be ok, and behaving as expected using the prebuilt firmware.
3.  Running Efinity v2021.2.323.4.6 on WSL Ubuntu 24.04 (this appears to be the version the seveni92t project was last compiled in, have also tried the latest Efinity version w/ same outcome)
4. Using the source from 7i92t-hm2/seveni92t.xml
    - uncomment line 114 of TopEthernet16HostMot2_efx.vhd (appears to be the top file for the project?)
       114: use work.PIN_7I76X2D_34.all; -- seed 5
    - comment line 110
      110: --use work.PIN_MX3660X2D_34.all; --seed 4
    - clean build, creates a valid binary file
    - this is the minimum reproducible, tried much fiddling with the source working back to here.
5. Flash new bin to the 7i92T and run same tests, no SS/Field IO

Output of --sserial query:
Dumping the hmid, the outputs (for factory firmware and the freshly compiled) are identical with the exception of line 11:
Clock High frequency: 175.0000 MHz on the new firmware and
Clock High frequency: 180.0000 MHz on the supplied.

I also note that comparing a hex dump of the two bin files shows significant differences, but I'm not familiar enough with the toolchains involved to know if building on different environments should lead to variance in output.

Any suggestions appreciated. Cheers.

I think it is not the right version the ip address is 192.168.96.54 and the linuxcnc config file there is an error

Hi all, 

Looking for some help with my closed loop spindle. It's a no-name "AT4" chinesium VFD driving a 3kW motor and a 2.2:1 belt drive to a BT30 spindle. Control is 0-5V from a 7i76e, encoder feedback from the motor shaft. The encoder is a 2500ppr unit I had left over so I'm only using the index pulse and have the encoder in counter mode because the A/B pulses were too fast. Encoder feedback into a 7i89.

Anyway, with P only control, I see the motor hunting a lot, a slow oscillation a few hundred rpm triangular wave, but I don't think it's as a result of too high P : there still a significant offset error so the oscillation is maintained even though the error is always a negative value (spindle slower than target). Lowering the P more increases the offset but doesn't change the amplitude or frequency of the oscillation, increasing P moves the speed closer to the setpoint but again no change in the oscillations. No screenshot but I can get one later on. Because it "hunts" even though the error is large and always one side of the setpoint makes me think it's not true hunting like a system with overly high P gain? The oscillation doesn't decay over time.. same behaviour with P anywhere from 0.8 to 10. 

I reduced P way down (to 0.5) and tried to get it working by using D to stop the oscillation and I to actually hit the setpoint, but it's still a bit shit so I think it could be much improved. I added a ramp constraint to the speed command to stop the vfd erroring out. There's an accel limit on the VFD side too so maybe that's affecting the control loop?  

It's getting to it's setpoint now but there's an over-acceleration initially, then a ramp that doesn't quite keep up, and then a weird over/undershoot/dip when the ramp ends and the I term seems to take over to slowly creep the speed to the setpoint. 

Can anyone who knows controls better than me suggest a methodology to follow to improve this?

if the drive is in PREOP, it would not move. There is some kind of error. It should be described in dmesg

Cheers Mark.

I don't get to do as much ally as I'd like.

Bit of a progress update from the last couple weeks:

Control panel is at the powder coaters. I choose a dark matt charcoal. Mainly as my coater runs this Dulux colour often and Im impatient at the best of times! Should have this back on Tuesday.

The custom control panel buttons are now 3d printed, along with the MX switch carriers. All wired up. These run into a DB25 breakout board and then will travel back the Mesa cards in the cabinet. I appreciate this isn't the nicest way to execute it, but I only require the 7i97t and 7i84u for all IO, and most IO terminates in the cabinet. I got cold feet on flashing the 7i97.... Pics below.

PC has been setup with linuxcnc. I chose a Coofun CK41 miniPC, which The Feral Engineer made some tests on YouTube with seemingly good results. Fingers crossed it works out. It's very compact and so was the price tag. Took me a few nights to get MesaCT and an updated Mesaflash running correctly to recognise the 7i97T. This is honestly due to my lack of unix (or IT in general!) skills. We got there in the end - I'm now able to run a draft linuxcnc config and toggle a coolant assigned output on the 7i97t with no dramas. I'll take that as a win. Yet to hook up the 7i84u.

Have to thank JT for the great MesaCT package!
I was and still am very daunted by the task of editing lines in the Hal/ini files.

The servo drives are currently on their way from China. I went with Leadshine EL7 drives in the end. The price was decent and they're offered in 380-400v 3ph. Opted for analog/pulse control as these control methods appear to be well documented here, especially by Tommylight's guide. Ethercat looked appealing, but given my lack of IT skills I thought it safe to stick with the aforementioned.

This weekend I started drafting the wiring diagrams between the Mesa boards, original Bridgeport control/distrubution board and new servo drives. The free schematic cad on DigiKey.com ist great btw! Would recommend.
Which brings me to my next question:

I assume I can run the enable controls from the 7i97t to drives without a relay? I believe I've drawn this with the correct polarity directions, but any insight are most appreciated.

More updates to come!

Cheers,

j

 
 
 
 



 

I have EtherCAT AC Servos with 23-bit multi-turn absolute encoders. I am trying to configure my "home" position. Is there a definitive documentation on using absolute encoders?

My absolute location is not where I want G53 "home" to be, in the case of the below and the provided INI sniplet, it's 7.3033 inches from the zero location I want.  Reading the documentation, it states to set HOME_OFFSET, and I also see a forum posts to set HOME. I feel like I am just guessing.  I have tried both, and neither works.  Also, I should never have to "home" the axis, correct?