Advanced Search

Hi there,

I'm setting up some surface grinder automation for some use cases where calling subroutines isn't quite dynamic enough (hal parameters change mid-job ), so being able to override things with my own python has been immensely helpful! I have discovered a problem unrelated to that though, this is reproduceable without importing any python. It happens when loading a custom hal module and the module, unaware of flexgui, issues MDI commands.

I am running multiple MDI commands in a different process that is triggered by HAL pins. Flexgui is switching the hal state in order to manage the background process. That part is working great.

It seems that flexgui has some code that watches the interp state, and if an MDI command is done, switches the task state back into MANUAL. My first command sets it into MDI mode, executes one MDI command, executes a second, waits until it's complete, and then the loop restarts. By the time the second loop iteration starts setting the MDI mode, it seems that flexgui is attempting to switch the mode from MDI back to Manual. Even if I switch it to MDI again before each MDI command, flexgui has switched it back to manual before my next MDI command can run. Future loop iterations, even though they switch to MDI mode at the beginning of the loop, don't stay in MDI mode before the next line runs.

This doesn't occur for any MDI commands sent via the UI thread, I assume because it's happening within the same update frame as flex is running in, so everything happens sequentially. That or the race condition has a longer time interval, so less of a chance for it to happen. It's very easy to make it happen when there are multiple processes or threads however.

I've narrowed it down to these lines in the below commit, removing it makes this all work, and preserves the functioning of the MDI tab along with it's history, but I'm not sure what implications this might have on anything else that flexgui is doing with it.
github.com/digiexchris/flexgui/commit/9f...d882032d85a41f7968d3

A minimal reproducable example would be this:
github.com/digiexchris/qtpyvcp_grinder_t...der_touch/process.py
and place the following at the end of your main hal file:
loadusr python3 process.py

It will delay the loop by 10 seconds in order for you to clear estop, set the machine to on, and home it.

Then the console you started linuxcnc in should start to give you the following output, and does using Touchy and Axis:

Loop
Current mode: Manual
Current mode: MDI
Current mode: MDI
Current mode: MDI
Loop
Current mode: MDI
Current mode: MDI
Current mode: MDI
Current mode: MDI
Loop
Current mode: MDI
Current mode: MDI
Current mode: MDI
Current mode: MDI
Loop
Current mode: MDI
Current mode: MDI
Current mode: MDI
Current mode: MDI
Loop
Current mode: MDI
Current mode: MDI
Current mode: MDI

and you can watch the X coordinate in the UI oscillate between X1 X2. 

In Flex, 

Loop
Current mode: Manual
Current mode: Manual
Must be in MDI mode to issue MDI command
Current mode: Manual
Must be in MDI mode to issue MDI command
Current mode: Manual
Loop
Current mode: Manual
Current mode: Manual
Must be in MDI mode to issue MDI command
Current mode: Manual
Must be in MDI mode to issue MDI command
Current mode: Manual
Loop
Current mode: Manual
Current mode: Manual
Must be in MDI mode to issue MDI command
Current mode: Manual
Must be in MDI mode to issue MDI command
Current mode: Manual

Occasionally you do see it go into MDI for one iteration, but flex is usually pulling it into manual pretty quickly. For some reason, When I control the loop with a HAL pin, which is changed by flexgui, the first iteration of the loop works, and subsequent ones fail with the above reasoning. But I suspect that's just a side effect of the GSTAT polling and handlers slowing the UI thread down enough for the first loop iteration to work.
 
Any suggestions? Auto mode doesn't work because I can't have the interpreter load the entire gcode program from the start, it's generated as the job progresses, kinda like how gcode is streamed to a 3d printer. Ideally I'd prefer if this behaviour matched Axis and Touchy (who have intentionally maintained the ability to execute multiple MDI commands sequentially with one mode switch)

Hi Aciera,

Thank you for the response and sorry again for the delay.  

I am glad to hear that motion.adaptive-feed is available and useful for what I am trying to do.  I have a couple questions. First, and more basically, how do I turn on motion.adaptive-feed? I found some info on the "motion" page, but it doesn't seem to show how to manipulate it.  Is it on the .ini file? 

Second, and more specifically, how would I get the machine to move backwards, but only when it is sensing a short.  There is an output from the EDM power supply that goes either high or low (I am not sure which) when the supply senses a short. Probably what I want is when a short is detected for the machine to move back a specific amount (in either distance or time) to make sure the short is completely gone before reengaging. The other option is simply to reverse feedrate until the short is no longer detected and then proceed with forward motion.  

I have no idea where to even begin to program this though... :/

Best,
-Dylan

Without a differential probe it's pretty hard so see,
but position recovery really seems like a drive or mechanical stall issue.

Can you set the drive following error limits tighter?

If it's possibly a drive strength issue, you could try single ended wiring.
(Since the drives have optoccoupler inputs this should have little effect on noise immunity)

 

In addition to the two polarities that need to be right
(TX to REQ and RX to data) The DPLL needs to be setup to
start the transfer _before_ LinuxCNC reads the data

I'll try and dig up a sample FANUC hal file Monday
 

It's fixed for all now

Some debugging. Per update above, mechanically things seem fine- I can shove the Y axis around and it's definitely not moving as much as the undercuts previously mentioned. I measured those, and the deepest is maybe ~0.01"/10 mil/0.25mm. Not as bad as I thought, still entirely unacceptable.

See attached pictures for some scope traces of one of the Y axis quadrature phases. Note that the measurement setup wasn't great for this, so there might be more noise represented here than is present in normal use- scope leads were dangling from jumper wires wedged into the cable ends, so... yeah.

With nothing moving, the signal idles at 5V +/- ~1.2V. Moving the X axis doesn't seem to influence this at all. Enabling the spindle adds some noise, dropping the signal as low as 2.3V. That's quite possibly enough to create false motion- minimum input to the servo is listed at 4V, but it also says it has digital filtering against noise, so... who knows. I should look at both A and B phases at once, but ran out of time. The fourth picture shows the Y axis moving- it's pseudo-differential, which in this case I don't think is actually buying anything, since the motor inputs are opto-isolated.

All of the above seems suboptimal, but I'm not seeing how it would somehow create extra steps in -Y, then somehow seemingly exactly recover them when going to +Y. Unless I want to level-shift, I'm not aware of a way to get the 7i76E to output > 5V on the motor control pins.

Anything else I should check? I'll plan on getting traces of both A and B phases simultaneously. Is a 3D model of  the issue still helpful, or is the cross-section sketch sufficient?

I have created a basic .hal and declared the Fanuc channel, see attached .hal.

I am getting an error on startup of linux cnc:
 

When I watch the corresponding hal pins and turn the encoder I am not seeing any activity.

Any tips on what to check or adjust next will be greatly appreciated.

Screenshots before and after?

Hi All,
  I have been reading this forum for weeks now, and have managed to solve most of my problems without needing to ask a stupid question, But the time has come. Be gentle, this is my first post.   I will attach my files to this to help.
Current Setup:
Dedicated computer running Linux Mint Debian Edition 6 "FAYE"
LinuxCNC 3.4.1
Gmoccapy gui
3040 Chinese CNC controller.
XYZ motion, although it also had the forth Axis, I am not including that in my setup.
7i76E motion controller card
0-10V AVI
24000 RPM
800W water cooled Chinese spindle.

My files have been created with the PNCCONFIG wizard.
I have now reached a point where every time I run the wizard, it breaks something, and I have to roll back changes.
(Even when I change NOTHING, just click through the wizard, it still breaks my setup, and will not start.)

I have been carefully trying to edit my files manually, baby steps, and backups!


PROBLEM:
I am having trouble getting the spindle to correctly work in the Gmoccapy display.
I can turn on the spindle, and turn off the spindle
I have the spindle start at 5000 RPM, and this works.
The bar graph on the bottom shows  "5000                  0                  24000"
It starts at 5000, as that is my (min) setting, and the "0" in the middle would display a percentage if I could only increase it.
I cannot adjust the speed of the spindle in the Gmoccapy GUI as there are no speed controls.

I want to add speed controls. and I have tried to understand what is written here in this post,
but I just cannot get my head around what I am doing wrong.

May I ask a member here to please look over my files? Perhaps it is something easy?

Thanks in advance!
Swanie

 

Firmware flash successful.

All wired up to the RS-422 connector. I will see if I can figure out how to put an instance of Fanuc Encoder on the .hal.

Any tips welcomed.

Hello,
is there also a 4th axis plotter available?
thanks!
best regards
anton

Hello everyone,
I'm having some latency issues on my EC500 freshly flashed with remora-rt1052-3.1.3.bin
Thanks to ColdTurkey's tutorial, I got it working (skipping the optional step #2 "Upgrade Kernel to 6.3RT" and #3 "FOR REALTEK NIC ETHERNET LATENCY ISSUES"), the led turns on when I get LCNC out of Estop.

Though, when I start linuxcnc, I get an error: "Unexpected realtime delay on task 0 with period 1000000" (config: remora-rt1052-basic).
Obviously, I though that skipping step #3 was a stupid mistake, so I followed through:

• Running sudo ethtool -i indicates a mismatched between the driver (r8169) and the firmware-version (rtl8168g-2_0.0.1 02/06./13)
• The next step was to run sudo geany /etc/sources.list but the file was empty so I ran sudo geany /etc/apt/sources.list instead and commented out the first line (deb cdrom:[Debian GNU/Linux 12_Bookworm...)
• I got to the next step and figured I'd run sudo apt-get install r8168-dkms like the example because there wasn't a packaged named rtl8168g.
• Then, I ran sudo ethtool -i  again and found out that the driver did in fact changed to r8168 but the firmware-version line was now unexpectedly empty.

To make sure everything was fine, I ran "sudo dmesg | grep r8168" and got this:
Still, following these steps didn't fix the latency error message.
Rebooting doesn't seem to help, as a newbie, I'm clueless haha !

Also, I should mention that running apt get update gives many errors:
Thanks you for your help !

Yup, worked. Thanks. I will now proceed with the rest.

set W17 up, power cycle  the 7I97 and try again

W16/W17 is 192.168.1.121
so ping of 10.10.10.10 will fail because there's no device with that address
and ping of  192.168.1.121 will fail because there's no route because of the host setup

Haven't gotten very far... can't seem to connect correctly to the 7i97 card. Here's what I know:

-Setup via 'edit connections' gui
-IPv4 settings as 10.10.10.11 netmask 8, checked 'use this connection only for resources on its network' under routes.

When I ping 10.10.10.10 the LEDs flash on the 7i97 in a certain sequence and terminal gives:
No detection of ethernet board from mesaflash.

Pinging 192.168.1.121 does nothing, terminal hangs.

Jumpers W16 & W17 are both in low position.

Board was opened from factory seal this morning.

Let me know what to look for next. Thanks!