Advanced Search

If you don't get a power LED at 5V, that's not a good sign
as it may indicate a 3.3V power issue (bad chip?)

Ya, I tried #5400 direct, but that section of code still gets bypassed.

Here is the last version:

O120 IF [ #5400 EQ 99 ]
G53 G1 F[#<_TravelFeed>] Z[#<_TravelZ>] ; Move Z0 for traveling
G53 G0 X[#<_ProbeStandOffX>] Y[#<_ProbeStandOffY>] ; Move to probe stand-off position
ELSE
G53 G1 F[#<_TravelFeed>] Z[#<_TravelZ>]
G53 G1 F[#<_TravelFeed>] X[#<_ToolChangeX>] Y[#<_ToolChangeY>] ( Moves to tool setter for manual tool change )
O120 ENDIF

I tried adding some msg lines to see what the passed value of #5400 is, but it doesn't seem to work. Thoughts?

This is only available with remap M6. Just use #5400 ?

Thanks for the suggestion. Changing the code as you suggested, upon restarting, I get a "Named parameter #<tool_in_spindle> not defined.

Hi, that Sounds Like a big Project to convert. For Pokeys57U i think you also use an PoExtBusOC16CNC as Steppgenerator? I wonder If IT makes sense to use your mach3 configurations AS Base for conversion to a linuxcnc HAL. I heard that the configurations are stored in some XML Files but i have No Idea about the structure of These File(s?).

the comp In "Page 10" can Just read/write Pins ( digital in) for movement you'd need to use the PEv2 as Pulse generator for stepoers. In 2.8 i got IT working so that o could move the axes, but the came to the homing topic which caused that i Had to move to 2.9.2 where had Strange issues (AS reported in one of my previous Posts Here).

Some weeks ago i started to Work in that topic again an currently found Out that in 2.9.3 some of the issues reported before we're Not reproducible. But still have Performance issues when i add the pokeys_homecomp in the ini for homing
My actual configuration can be found Here github.com/zarfld/LinuxCnc_PokeysLibComp i did a rough description maybe that helps a bit ( it's far from being a full and structured technical documentation) For now i think to keep IT running in Carport until i could fix the homing topic, i you want to give IT a try i could also Help on updating your HAL and ini based on your machine.

You can try #<tool_in_spindle> instead of #<_current_tool>

; New stand-off position for the probe (T99)
#<_ProbeStandOffX> =   1135.0    ; X coordinate for probe stand-off
#<_ProbeStandOffY> =    516.0    ; Y coordinate for probe stand-off

O120 IF [ #<_current_tool> EQ 99 ]
        G53 G1 F[#<_TravelFeed>] Z[#<_TravelZ>]                ; Move Z0 for traveling
        G53 G0 X[#<_ProbeStandOffX>] Y[#<_ProbeStandOffY>]  ; Move to probe stand-off position
     ELSE
        G53 G1 F[#<_TravelFeed>] Z[#<_TravelZ>]
        G53 G1 F[#<_TravelFeed>] X[#<_ToolChangeX>] Y[#<_ToolChangeY>]  ( Moves to tool setter for manual tool change )
O120 ENDIF

The top section never gets qualified, even though variable #5400 has 99 stored in it.  

I'm not sure this will work anyway.  I want to put in the typical M6 T99, and perform the tool setter routine.  But in my case,
I want T99 to send the probe to a fixed location instead.  All other tools, ie;  M6 T2 would go to the tool setter. 

 

And for you probe fans Flex can now get user parameter values on startup and change them from the GUI.

Quite a few folks on the IRC use Flex GUI.

Is anyone here using Flex GUI?

JT

The card arrived. PCI to parport Sunix. Looks like it works.

But I try to power the 7i43 and it looks like it is faulty. With W4 and W5 down I can make the 3 leds on the bottom light a little bit at 2,9V and 0,5A. But at 5V and around 0,4A nothing shines anymore. Looks like somithing is wrong.

Yes, reverse feed is possible and also used in EDM machines that use linuxcnc,

 

Hi all!

I've been trying to use wiznet w5500-evb-pico as step generator for linucnc.
I was successfull loading remora-rp2040-2.0.0.uf2, from github.com/scottalford75/Remora-RP2040-W5500

But, when trying to compile, i was less lucky:

/tmp$> cmake -DPICO_SDK_FETCH_FROM_GIT=on ./Remora-RP2040-W5500-main/
/tmp$> make
I've got some include errors like: pico_bootrom/bootrom.c:9:10: fatal error: boot/picobin.h: No such file or directory
#include "boot/picobin.h"

The same for: runtime_init.h,runtime.h
But those files are available in the sdk source.

My Q&D solution was to copy locally to complete the build.
After that, the build made a loadable uf2 image.
But the rp2040 has been crashing during my tests.

Suggestions?

Gluca.

Was this on another topic a while back, or is it another setup/machine?

O.M.G. - I should RTFM

spindle.M.revs IN FLOAT
For correct operation of spindle synchronized moves, this signal must be hooked to the position pin of the spindle encoder.

Ignorance is NOT bliss.

PCW wrote:

It should still work with the tristate bit connected, as long as the tristate enable pin is false.
 

Thanks, I'll reconnect it.

Shocking development: I've managed to get the spindle orienting without using the shot-pin, and without having to set index-enable true and rotate the spindle to re-find the index.

Based on Andy's advice a couple years ago, I had connected pid.o.error to pid.o.Pgain through a lincurve array.  After watching things in halshow today, I discovered that Pgain wasn't changing in response to the orient error; i.e. lincurve wasn't doing anything.

Turns out I had the lincurve starting x-values set to an order of magnatude smaller than required for lincurve to adjust the output.  Result was that lincurve didn't 'kick-in', ever.  The shot-pin was required to lock it in place because the pid wasn't adjusting - just causing the spindle to wag back and forth.

After changing the values and connecting pid.o.index-enable the spindle now orients from any position.  No shot-pin, no pre-orient spin-the-spindle index-enable dance.

Sadly, this hasn't fixed the rigid tapping failure.