Advanced Search

I still have a weird issue that I am thinking is my hardware somehow, I can connect in the test GUI, see inputs, quadrature encoders and toggle outputs, but the terminal window keeps saying received data have wrong header. I have triple checked pins for conflicts. Apart from the terminal spamming that message it seems to test OK. 
Unfortunately LinuxCNC won't get out of estop, and spams wrong header size.

I am still treating it as my hardware, going to setup a different PC, I took out the Tang Nano that is in my milling machine and flashed it but the fault persists. If not the PC, I'll start swapping out PCB's from my two working machines.

Worst part is it was all working nicely last night.

Update,

I have successfully added the emergency stop button. The problem was with the Mesa 7i95 board's nomenclature used for input/output pins. I was using the wrong pin (hm2_7i95.0.gpio.000.in). The correct input 00 pin for the Mesa 7i95 board is inmux 00 pin (hm2_7i95.0.inmux.00.input-00). Below is the code added to the hal file...

net estop-out iocontrol.0.user-enable-in
net external-estop-in hm2_7i95.0.inmux.00.input-00 => iocontrol.0.emc-enable-in


The next problem is still pending about the feed override.
Thank you, Benb and PCW, for your input. You are correct that I want to control feed override using external analog voltage control (cRIO-9045, NI-9775, LabVIEW Software). I have never modified the Mesa default pin configuration, and I am trying to search for how to modify the Mesa board pin configuration. It would be great if I could use the motor or encoder pin for analog input. I request that you give me more ideas/references to do the same. As PCW suggests,  "The 7I95/7I95T has no analog input, so an encoder is probably a better choice." Kindly give more hints on how to use the encoder to control the feed override using external analog voltage control (cRIO-9045, NI-9775, LabVIEW Software)

Another idea I am thinking about is serial communication using the serial port available in the Mesa board; there are two serial communication ports (serial 1, serial 2). But at the moment no idea how to do this as well.

Another thing I was trying to identify was the pin/parameter that is responsible for feed override. In Axis GUI, there is a button for feed override, but I am not able to locate the corresponding pin and parameter in the Halshow Configuration window. I do locate one pin, but it is saying it is not writable. A screenshot is attached.

Thanks

was my mistake, normally I give a warning/error if a pin is used twice, but I had once installed that you can use input pins more than once and forgot to check if both pins are marked as input.

is fixed in dev branch

Hallo ich habe den Test an 2 Verschiedenen Mesa ausgeführt

My first guess, with a quick lock over your files, is that you mentioned directly in the beginning that its an non CIA402 conform drive.
So my first question is why did you use CIA402 in your hal?
Maybe you should connect each PDO which you need from your XML with the correct hal pin over lcec so that you always connect with the right pdos. With the CIA402 you cannot really say...

For your info i bought the ES580 with a Lusintun Spindle and i will go nearly the same path with the Ethercat board, so maybe we will find a solution together...

Can I use this project for 4 analog pot inputs rapid feed spindle and jog speed?
Arguino pro mini will work ? 
How I will connect with PC with ttl2USB adapter or it is better to use leonardo that has USB interface?
What about esp32 will work with this?

It's the Realtek hardware, nothing wrong with ethernet chip used by Mesa.

I updated the ethernet driver and t seems to be ok now. It appears its an issue with mesa ethernet boards and realtek hardware which is how i found out about it. seems its an issue with EtherCAT as well.

I'm setting up my tool height setter and am having a similar issue.  It is not happening every time, but I'd say around 50% of the time i run the command.  I am running 2.9.4, gmoccapy and on an intel N100 PC and have no other latency issues.
Full error line is: emc/task/emctask.cc 68: interp_error: Queue is not empty after probing.  The other odd thing is when I don't get the error, #5063 will have a good value in it, but #5070 never gets set to 1

Gcode for the probe sub:
o<tool_probe> sub
O100 if [#<_task> EQ 0]
O100     return
O100 endif
G17 G20 G49 G90
G0 G53 X35.52 Y13.415
G0 G53 Z-7.0
G91
G38.3 Z-4 F10
(DEBUG, Z#5063)
G90 G53 Z-4.0
o<tool_probe> endsub
 

Thanks for checking things over PCW!

I can't setp the value since it's linked to a signal, but when gcode runs M67 E0 Q0, GPIO 017 does go false.

'setp hm2_7i76e.0.pwmgen.00.scale 100' has been added, this may yield better results. Since I didn't set the scale, all values (1-100) were sending full power. This tip right here may be the biggest sanity check, thanks PCW!

The connections look OK

If you set the PWM value to 0, does GPI0 017 go false?

I don't see that the PWM scale was set so anything >= 1 will be full scale
(default PWM scaling is 1.00 = full scale)

If the PWM values are in percent, you probably wantsetp hm2_7i76e.0.pwmgen.00.scale 100

in the hal file



 

Use Rufus to write the ISO to USB, or Balena Etcher should also work.
Also make sure the BIOS is set to boot from USB first, or, press repeatedly the F12 button at power on till you see the bootable device list. F11 on some PC's, F8 on Asus, etc.

You can wire the drives directly to Mesa and get rid of the parallel port boards.

pushed the 'last run line' log - see what you think.

I've got to get better at asking the right questions... Using the old config:

signal 'sj'
motion.analog-out-00, and
hm2_7i76e.0.pwmgen.00.value

All these values update as M67 changes the output.

hm2_7i76e.0.gpio.017.in toggles to True when the gcode starts running.

Does everything seem mapped right for the PWM to reach pin 1 on a 5 axis breakout board? Should that be on hm2_7i76e.0.gpio.017.in? Maybe the code is fine, and I should be chasing down a hardware issue?