Advanced Search

My effort is to learn g-code subtleties that are new to me as well as to improve my python coding abilities.  Consequently, I trying to fully automate the measurement process. To that end, I decided that I could combine both Andypugh and JT's approaches to first capture the data with a g-code script then process it with python.

As I studied o-code subroutine examples I attempted to use an internal subroutine with Andypugh's suggestion for a more elegant approach. I've attached my code for your inspection. 

When I load the code into LCNC this warning is raised:

 Near line 40 of ./check_level.ngc "Bad character '>' used". 

I'm lost as it appears that the code follows the examples in the documentation. Please help me understand the issue.

Kind regards

I'm loving hearing this, as I've never used RPI I was interested for two reasons, one because it's very compact and the other because it uses its compact and cheap touch screens, but I'm afraid I'll have difficulty as I've never touched one and I need a lot of help from you... In parallel to this subject in relation to 7i92H, how do you do in relation to the spindle since it doesn't have a 0-10v analog output?

Hi Andy,

Thank you — your reply has pointed me in a couple of useful directions.

The current logic comes from another Boxford conversion running a Pi, though that one was a 125 (not mine) rather than a 240. That said, I stripped out most of it and was still encountering issues.

It’s GPIO14; I just hadn’t updated the comment yet as I’d moved pins to double-check something.

I have, however, found the G95 issue. The problem was that spindle.0.speed-in was connected to encoder.0.velocity-rpm instead of encoder.0.velocity, so the motion planner was seeing a speed sixty times faster than expected. Correcting that resolved the issue.

Most of the encoder speed problem stemmed from not having a sufficiently fast base frequency, which meant it was under-sampling and missing the index input. Moving the index pulse to an EC300 Remora pin has fixed that.

It’s not perfect, but it’s enough to get most things running until I can sort out a better encoder. I’ll probably follow your suggestion and add a second sensor offset by N+¼, although that will take some planning — the slot sensors are quite bulky, so getting them close enough will be tricky.

I’ve had to retain part of the spindle logic, as my servo input for analogue speed and direction is –10 V → 0 → +10 V. Because of that, I’ve kept the abs portion to strip the sign so that the DAC section only ever sees a positive voltage. The spindle is then reversed using two relays that invert the normal 0–10 V signal.

Unfortunately, I’m still not getting a stable speed above 1900 rpm. I suspect this is due to the sampling of the 100 PPR disk — when I decrease the base period, the speed stabilises, and by reducing it further I’ve managed to get stable(ish) readings up to around 1900 rpm. Above that, HAL Scope just sees phase A as high rather than a pulse train.

The good news is that feeding using G95 works when using the MDI.

The bad news is that no programmes will run. I get some movement when single-stepping through, but no feed. I now suspect this is because the programme uses CSS, and given the above issues, the control isn’t seeing a stable enough RPM for CSS to function correctly. I’ll try running the programme without CSS tomorrow to confirm.

If that doesn’t help, it’s probably a “spindle at speed” issue — though that signal does appear to be set correctly when the spindle reaches speed, so I’m not entirely sure.

Yes i am, i have 3 or 4 of those in daily use, 1 with Proma THC150 and others with Mesa THCAD.
I also have a china one with same electronics and pilot arc, the HF type, i intentionally wired the THCAD10 to the main terminals with 1MOhm resistors on each side, still in daily use for nearly a year, no issues.
The thing is, with correct wiring and grounding and shielding, it works fine, but any wiring error will result in burnt electronics the first time the torch fires, hence i refrain from advising such things.

Maybe this thread would get you going in the right direction.

forum.linuxcnc.org/subroutine-library/51...asic?start=10#336942

It works now...
I have two network adapter. One intern and one USB. My Internet was connected to the USB adapter. This doesn´t work. I switched to the intern adapter and now itś fine...

Are you sure, Tommy? It got HF start.

www.linuxcnc.org don´t work
Reddit    don´t work
Youtube work
Google  work

My Windows Laptop (WLAN) and my Smartphone (WLAN) have no problems

Works here.
Can you access google or youtube or www.linuxcnc.org ?

Nilres wrote:

All Stahlwerk Cutters have a build in THC Connector.

Black ones, maybe, the white ones not all for sure.
They are good and have a few years warranty, but aim for 70A at least, the exact one that Hakan proposed.

Hi everyone,I’m currently using Probe Basic UI on a 3-axis milling machine. Tool setting and probing are working perfectly — kudos to everyone who made that process so smooth.However, I ran into a potential issue. I noticed that the .ngc file generated from Fusion360 only prompts for a tool change (e.g.) without performing any actual tool change or probing routine. That’s risky — I almost started a job without realizing it wouldn’t automatically run the tool-length probing cycle after each change.I’d like to make the workflow safer and more automated. Ideally:

• Whenever a tool change (

  M6

  ) is called, the machine should automatically go to the tool probe and measure the tool length before continuing.
• No manual pause/resume or separate probe command should be required — it should just happen as part of the

  M6

  sequence.

Would this be best handled by:

• A custom M6 remap in the HAL/INI file, or
• A modified Fusion360 post processor (.cps) that inserts probing commands automatically after each tool change?

Also, I noticed another small issue:
The spindle starts cutting immediately after thecommand, without waiting for it to reach full speed. I know I can tweak ramp or lead-in settings in Fusion, but I’d prefer a permanent spindle-speed wait in the HAL or remap (something like a delay or “wait-for-at-speed” check).For testing, I’ve been running with the spindle disabled and using a pencil in place of the endmill — so nothing dangerous, just making sure all the logic works before real cutting.Any guidance or examples of how others have integrated automatic tool probing and spindle speed waits into Probe Basic or LinuxCNC would be much appreciated!Thanks in advance

I started looking into to this and while I haven't been able to pinpoint the cause yet I found these lines of code in vtk_backplot.py

 

The lines highlighted red and yellow seem to be duplicates of each other and the ones marked green don't seem to be used anywhere.


Digging a bit further it seems that the path_offset_start_point dictionary where the KeyError comes from only gets written to in one location (marked orange below).

 

So I assume that the dictonary is supposed to be populated with values via the VTKCanon class.

 

That'd be amazing. I'll be putting some more time into the setup tomorrow so I'll get in touch once I'm back at the machine.

Hello,
yesterday i installed a fresh Linux and Linuxcnc. Today i received a handwheel for my mill. During the installation prozess i have to use the terminal window with the command:git clone github.com/LinuxCNC/linuxcnc linuxcnc-dev I get this error:
Cloning into 'linuxcnc-dev'...
fatal: unable to access 'github.com/LinuxCNC/linuxcnc/': Failed to connect to github.com port 443 after 3 ms: Couldn't connect to server

 I can´t reach many https sites. Any ideas? I don´t have a proxy and (probably) no firewall

Thanks

Thanks, i installed a new linux