1. Forum
  3. Search

Advanced Search

Search Results (Searched for: )

  • Aciera
  • Aciera's Avatar
16 Apr 2025 06:16 - 16 Apr 2025 06:30
Replied by Aciera on topic Remap M6 in python

Remap M6 in python

Category: General LinuxCNC Questions

The task check to avoid execution on load can also be put into the ngc remap like this:
o<g123remapwrapper>sub
o100 if [#<_task> EQ 1]
M66 L0 E0           ;force sync, stop read ahead    
(call your python remap here)
M66 L0 E0
o100 endif
o<g123remapwrapper>endsub
m2


Also, as you have already found out, the 'print()' statements are actually executed during read ahead. If you want messages from the command queue you could use something like this:
    self.execute('(msg,your debug message here)')
  • unknown
  • unknown
16 Apr 2025 05:54
Replied by unknown on topic 7i92 firmware issue

7i92 firmware issue

Category: Driver Boards

Of course, having a "senior moment".
  • Aciera
  • Aciera's Avatar
16 Apr 2025 05:36 - 16 Apr 2025 06:49
Replied by Aciera on topic Remap M6 in python

Remap M6 in python

Category: General LinuxCNC Questions

Python remaps are tricky to get right. I'm no expert but I have done a lot of trial and error during my work on Tilted Work Plane codes which uses a fairly complex python remap (although no M64, M65 usage).
github.com/LinuxCNC/linuxcnc/blob/master...ting/python/remap.py

On this background I would like to point out a few general things:

You might want to put something like this at the beginning of your remap so it does not execute on load:
if self.task == 0: # ignore the preview interpreter
    yield INTERP_EXECUTE_FINISH
    return INTERP_OK

Also note this restriction for the 'yield' feature:
 
linuxcnc.org/docs/html/remap/remap.html

which means that code like this is not allowed:
            if router_down:
                print("Raising Router (P14)")
                self.execute("M64 P14")
                yield INTERP_EXECUTE_FINISH
                time.sleep(2)
                self.execute("M65 P14")
                yield INTERP_EXECUTE_FINISH

instead you could use:
            if router_down:
                print("Raising Router (P14)")
                self.execute("M64 P14")
                self.execute("G04 P2")
                self.execute("M65 P14")



Premature execution of the python remap by the read ahead may also be a problem. While 'yield INTERP_EXECUTE_FINISH' at the beginning would prevent that it would also bar the use of 'self.execute()' after it (as pointed out above). My usual workaround is to call the python remap through an ngc wrapper like this:

o<m6wrapper>sub
M66 L0 E0                                                   ;force sync, stop read ahead    
(call your python remap here)
M66 L0 E0
o<m6wrapper>endsub
m2
  • electrosteam
  • electrosteam
16 Apr 2025 04:50
Gmoccapy Modal Display was created by electrosteam

Gmoccapy Modal Display

Category: Gmoccapy

Starting to use G54 and G55 to enable two job locations - new to me.
Test run a short program with G55 in the header.

In Axis, the Modal Display changes to G55 when a program is run, then back to G54 on completion.

In Gmoccapy, the Modal Display stays at G54, even though the DRO Display shows G55 while the program runs.

In each case, the DRO Display correctly shows the G55 Offsets and coordinates during the run time.

I think this must be a bug.
If so I can live with it.


 
  • notJamesLee
  • notJamesLee
16 Apr 2025 04:40
Replied by notJamesLee on topic Determining Angular Scale - Help w/ Microsteps

Determining Angular Scale - Help w/ Microsteps

Category: Configuration Tools

youre 100% right, not sure where i got 533 from.

I set it to 600 and its still over shooting. Probably about 1.125 rotations again.

I am having trouble believing its the driver because with the 1600 it works perfectly and repeatable (not sure that's a word). 

Maybe i need a sanity check on the layout of the belt system (simple diagram) attached. I dont think the tensioner (idler gear) makes any difference in the belt ratio calc (shout out uni for that one)
  • lrak
  • lrak's Avatar
16 Apr 2025 04:18
Replied by lrak on topic LinuxCNC 2.9.4 Released

LinuxCNC 2.9.4 Released

Category: Installing LinuxCNC

2.9.4 is released - but not in forum.linuxcnc.org/29-forum-announcements? 

Looking via Debian - it appears this is only in sid=unstable - so not yet stable or testing - so your install instructions won't work for anyone running anything other than unstable.

That being said, I currently have 2.9.0~pre1+git20230208.f1270d6ed7-1+deb12u1  under bookworm.
And have had some random resets.. Is there a list of what is fixed in 2.9.4 ?

So to install in bookworm you would have to install half of testing as dependencies.

I'm not complaining - like seeing the progress, but hope this might help others that run stable=bookworm. 

I put trixie on a laptop for non linuxcnc - runs well, but lots of libs are getting updated at a high pace as the freeze has been approaching .  trixie is supposed to release sometime in the second half of the year - when it is ready.
[color=#000000]The following packages have unmet dependencies: [/color]
linuxcnc-uspace : Depends: python3 (>= 3.13~) but 3.11.2-1+b1 is to be installed
                  Depends: libc6 (>= 2.38) but 2.36-9+deb12u10 is to be installed
                  Depends: libglib2.0-0t64 (>= 2.12.0) but it is not going to be installed
                  Depends: libgtk-3-0t64 (>= 3.11.5) but it is not going to be installed
                  Depends: libgtk2.0-0t64 (>= 2.8.0) but it is not going to be installed
                  Depends: libpython3.13 (>= 3.13.0~rc3) but it is not going to be installed
                  Depends: libstdc++6 (>= 13.1) but 12.2.0-14 is to be installed
                  Depends: libtirpc3t64 (>= 1.0.2) but it is not going to be installed
                  Depends: libgtksourceview-4-dev but it is not going to be installed
[color=#ff5454]E: [/color][color=#000000]Unable to correct problems, you have held broken packages.[/color]

Hope this is helpful.
 
  • electrosteam
  • electrosteam
16 Apr 2025 04:17
Gmoccapy Touch-Off Offsets was created by electrosteam

Gmoccapy Touch-Off Offsets

Category: Gmoccapy

3-axis mill with RPi 4B and LC 2.9.3 from Download page, and Gmoccapy 3.4.6 - runs a job fine.

Offset Values:
In Axis, Touch-Off populates with a value generally within 0.001 mm of the value entered
Minor corrections are often successful, but sometimes ignored.

In Gmoccapy, Touch-off x=0, y=0, z=0, G54 populates with a value, like z=0.511.
    - Touch-off often leaves small errors on the DRO, like 0.008 mm.
    - I seem to run in circles trying to get the Offsets Page to agree with the DRO display, the G54 values, and the current position.

Suggestions ?
 
  • electrosteam
  • electrosteam
16 Apr 2025 04:02
Replied by electrosteam on topic Gmoccapy Stop Mid-Run

Gmoccapy Stop Mid-Run

Category: Gmoccapy

Got some time to review mill operation.
Delving into G54 and G55 Offsets.

I think my problem was an attempt to travel beyond the Z- soft limit.

So, one of my current educational tasks is to try and get something like an error code displayed on a soft limit excursion.
As suggested, like HalScope or HalShow.
  • scotth
  • scotth
16 Apr 2025 03:42 - 16 Apr 2025 03:47
Replied by scotth on topic Linux_Mint_22.1_LinuxCNC_2.10.iso

Linux_Mint_22.1_LinuxCNC_2.10.iso

Category: Installing LinuxCNC

Ping times look super other than the glitch, also on the latency test.

Could it be a glitch in 6.13.
  • PCW
  • PCW's Avatar
16 Apr 2025 03:40
Replied by PCW on topic 7i92 firmware issue

7i92 firmware issue

Category: Driver Boards

SI = Signal Integrity (fussiest signal would be the clock)
  • unknown
  • unknown
16 Apr 2025 02:15
Replied by unknown on topic 7i92 firmware issue

7i92 firmware issue

Category: Driver Boards

I'll look into the power supply.

SI = serial input ?

Thanks again.
  • wrhammer
  • wrhammer
16 Apr 2025 02:06 - 16 Apr 2025 02:20
Replied by wrhammer on topic Remap M6 in python

Remap M6 in python

Category: General LinuxCNC Questions

That's the main file and forgot to attach it! Here it is Andy.
-edit: Attached the latest test remap that I haven't tried yet. Original attached.
  • PCW
  • PCW's Avatar
16 Apr 2025 01:23
Replied by PCW on topic 7i92 firmware issue

7i92 firmware issue

Category: Driver Boards

Maybe some power or SI issue at the Flash EEPROM?

The firmware has a 5 ms timeout for page writes (3 ms max on the W25Q16)
The erase timeout is 3 seconds (400 ms max on the W25Q16)
so that should not be an issue.
  • Silverback
  • Silverback
16 Apr 2025 01:07
Replied by Silverback on topic Inconsistent values from Versaprobe

Inconsistent values from Versaprobe

Category: Qtvcp

I was reading the qr_auto_probe_tool.ngc code and this line:

#<calculated_offset> = [#<touch_result> - #<_hal[qtversaprobe.probeheight]> + #<_hal[qtversaprobe.blockheight]>]

Appears that the tool length, #<calculated_offset>, should equal the distance between the probe length and the loaded tool length. It is saved using

G10 L1 P#<tool> Z[#<calculated_offset>]

Which would indicate the length of the tool "should" be the difference between the probe length and the loaded tool length. We can assume the #<youch_result> as zero if we reprobe the probe...I think.

However, I get -70.(Something) For my probe length and -90.(something) For my tool length when the tool is shorter than the probe. At least in the tool table.

I think it would work better if the probe touched off and then, instead of "work piece height" which may or may not be G5? Z0, we should just be instructed to probe the Z0 point and set the offset between the tool setter and Z0 as a constant. Then just add that offset to the probe height and be done with it.

I believe the coding to include block height in every calculation is unnecessary and can cause errors. Plus, and I realize it's not Python, but the code could be more readable if there was a single constant offset then just amending the new tool length by that offset.

I may well be way off base here, because I am new and the code is different than what I am used to. But, I think the height setting could be simplified a bit. Just my opinion. Not trying to step on anyone's toes because it's obvious they put a lot of work into it already.
  • unknown
  • unknown
16 Apr 2025 00:52
Replied by unknown on topic 7i92 firmware issue

7i92 firmware issue

Category: Driver Boards

Ran
./mesaflash --device 7i92 --addr 10.10.10.10 --verify ~/linuxcnc/firmware/7i92/TopEthernetHostMot2.bit

about 10 times passed every time.

Just for completeness tried verifying against another bitfile (not written to flash) and failed as expected.

Hold & WP are tied directly to 3.3v CS is tied hi via 10k resistor.

If the main clk is out, part is marked as 50Mhz, could this throw a spanner in the works ? But then that would affect the Ethernet Interface's 25Mhz clock.

It feels like the write is taking longer than expected, but checking the busy flag would mitigate this. That's why I thought of putting a delay between mesaflash wiritng a page and the "packet read for board syncing"
Displaying 6526 - 6540 out of 24275 results.
  1. Forum
  3. Search
Time to create page: 0.519 seconds
Powered by Kunena Forum