Advanced Search

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?

I would try the steps A,B,C of example 1 I posted earlier

ok that makes sense, and after spending some more time working on it, including taking the scale back to 10, i have it now in a pretty good spot where i would consider it time to start tuning.

does the halscope guide tommy put together also work for tuning torque mode PIDs? otherwise im currently hunting out an equally well put together guide so i dont resort to just changing numbers and seeing what happens.

Thanks langdos, I did a similar fix

I have absolute encoders, so I just set the soft limits.

Maybe there is an issue with hard limits? Should I report this? GitHub issues?

You can also have a look at the EasyCAT:
www.bausano.net/shop/gb/home/1-arduino-ethercat.html

you can hook encoder pretty easily to that for much cheaper. And it is also quite flexible.
Encoder counting happens on arduino and current count is sent over EtherCAT to LinuxCNC, which saves you some hal configuration.

RE: EL1819 vs EL1809 response time - i think it includes signal debuncing, so 3ms does not necessarily have to be bad, because it's slower than 10us.

100 mA is a typical value for 5V, at say 24V the current is much less for most contacts (closer to 10 mA)
A small capacitor across the contacts can provide the wetting current without a large constant load.

If the relay does not show closed at 24V, its likely faulty...
 

This should be it.  

Yeh, my post must have broke. If you look a bit harder on eBay you will find better priced moduled for around $130. Some want stupid money. Don;t be frightened of buying from other countries...

Failed again to leave my workshop early.
Sorry i am blessed with writing jam at the moment, but good luck for recovery from the injury