Advanced Search

I would try to use custom Mcodes/ subroutines directly and avoid using the python mdi command.

The key problem is that you don't have the battery and the corresponding encoder cable for recording the encoder position.

I fixed it by editing the necessary lines.

HAL
 

INI
 

IO
 

A Rotary switch 10 or 12 way or what every is available, then either use 10 or 12 inputs, or if you want to lower that use a priority encoder, would take up that much space or a simple diode matrix.
The little rotary encoders aren’t that bad as they usually have a switch included as well which could be for reseting the override.
Using a analogue mux would require a custom component to sync everything.
The pot or rotary switch gives a quick visual at where the override is without having to look at a screen. The rotary encoder not so unless you were to implement mechanical stops to limit movement over a certain range, but wouldn’t be compatible with using the switch for reset.
I was just thinking about the bit banging spi thing, it may require 2 thread slices per clock signal. As there are only 1 read & 1 write per thread.

SERVO_PERIOD = 1000000

INI file attached.

After more trial and error and checking the cables and slaves one by one, I am going to go with the working theory that the NIC is problematic in some way, as the biggest improvement yet was after I deleted the Ethernet connection it was trying to establish.

The onboard PC has two Intel I211 interfaces. I found this post and thought to try out the suggestions. I wasn't sure if I had the dkms driver for my interface, but lspci -v reported the driver as "igb." Upon some googling this GitHub repo came up. It seems there is (or was?) a known issue with I210/I211 NICs that causes the driver to terminate due to some checksum mismatch. I am not sure if this applies to me exactly, since even if it does terminate for me, it is not until the next reboot, but just momentarily - enough to spike the latency and desync the process. Either way, I wasn't able to install the patch from the repo as it is for an old kernel and sudo apt install fails because of that. Do you suppose I should pursue this further or has this issue with the driver been resolved by Intel in the past years?

The next thing I did was to add all of these kernel parameters:I also disabled EEE from ethtool.

I believe this improved things yet again since now the situation is as follows. On running a test program with a max velocity of 1500mm/min, there are actually no issues to be reported. It's been running for 4 hours already. However, upon increasing the velocity (the max is 6000mm/min), the program fails in about 30 minutes and reports a joint error, if I don't stop it before that because of the worrying noises the axis emit.

Due to this, I am seriously suspecting the NIC in general and the latency as the culprits. For the time being I will try out the suggestions in the Arch Wiki for realtime process management . I would nevertheless still be very grateful for any other help and ideas.

@PCW: thanks for the explanation - I was actually a bit annoyed by the one-liner Mesa response without any additional context/explanation. I was under the impression that it is a simple configuration issue and that the 7i73 is as easy configurable as the FPGA based cards. I obviously did not dig deep enough into the docs to understand the sserial features/limitations, sorry. I thought, that obviously others also might need more than 4 analog inputs sometimes - so I've expected that sombody else already stumbled over this issue and found the "missing" mode or settings...

With the new context, I am now thinking of a few workarounds (thanks to everybody for their ideas) to replace the missing analog input for a poti:

• Using an additional/external analog multiplexer (like 74hc4051) and use an output pin to switch between two potis (a few Hz update rate will be more than enough)
• Use an external A/D converter (there is some sample here using a bitbang SPI) for one of the potis
• Replace one of the potis with a small encoder 
• Replace one of the potis with a rotational switch (e.g. with 10 positions) and map each of the 10 inputs with a fixed percentage in the hal

Thank you very much for your offer to look into the code again - if it is not too difficult and helpful for others, then obviously it would be nice, if you could add another mode with more analog inputs.

Here is what I currently use:

• IN0-IN3: analog inputs for X/Y/Z joystick and the feed override poti
• IN4: would like to use this for the spindle speed override poti
• IN5-IN7: digital inputs: buttons
• IN8/IN9: ENC0 encoder wheel
• IN10-IN15: digital inputs: buttons
• KEY0-KEY5: used as LED driver outputs (as I use the NO LCD and NO KBD mode, they map to OUT10-15)

For me the easiest thing will be adding an external analog multiplexer or replacing one poti with a small encoder- thinking about the typical use cases of a pendant interface board, the analog multiplexing could also be possibly implemented in software (so others could benefit from it, too). This could allow to not violate the process data space but still add four (slow) analog inputs (in addition to the four fast inputs) - eventually with loosing one of the encoder inputs?
Please don't waste any time to implement a single user solution (for me) - I was expecting to get my config working with some configuration adjustments I've overlooked. If you think my use case could make sense to others, then adding an additional mode is of course highly welcome!

Let me know what you think!

Thanks and best regards,

​​​​​​​    Holger

How about this:
g53 g0 z#5183
g30

Wait_complete monitors linuxcnc status for the current message serial number.
It only checks if the current serial number is _past_ the commanded message serial number.

My educated guess is that since adjusting the maxvelocity sends more commands, the serial number gets changed and the check passes, even though it's the max velocity not the MDI that finished.

Using MDI programmatically is very difficult.

Nothing to worry about. The embedded window process is not perfect.

It's available in python as attribute 'settings'.
linuxcnc.org/docs/devel/html/config/pyth...xcnc_stat_attributes

You can also see it by using linuxcnc status program.

I think a line should be added to the bin file. How can I do this? 

Awesome. Those optocouplers are pretty cool, especially if you’re bad at wiring.
Thanks for the quick responses.
At least I know i didn’t break it, even if it doesn’t work.

Greetings, I like your tapping G code generator, we are looking at purchasing a cnc machine to do electrical panel backplates and I am looking at your G code generator. a couple of questions:
does it only run in linux, and if so, what linux software do you use, and also can you run linux on a virtual machine to make it work, and once completed, can you download into the cnc machine. Thank you for assistance - Bruce