Advanced Search

Hi all!

I've been testing on wiznet w5500-evb-pico the firmware
remora-rp2040-2.0.0.uf2, from github.com/scottalford75/Remora-RP2040-W5500

In boardconfig.h:

StepgenConfig StepgenConfigs[] = {{"X-Axis", 0, "GP02", "GP03"},
                                  {"Y-Axis", 1, "GP04", "GP05"},
                                  {"Z-Axis", 2, "GP06", "GP07"},
                                  {"A-Axis", 3, "GP08", "GP09"}};

It seems to drive correctly my step motors for X and Y, but for the
Z axis i get some sort of square wave around 50Khz!

With the oscilloscope, i've seen a square with fixed frequency on GP6.

Are anyone experienced anything like that?

Bye,
Gluca.

 

Looks like gksudo and the likes have been removed from Debian and Ubuntu.

One thing you could do:

And then modify the file without escalated privileges in any editor of your liking, then cat the file back:

Nevermind. Hardware fault. I must have a chip stuck in the analog pot. input.0.abs-y-position isn't going to zero (sticks at -~0.2) when released. So Y starts moving when the speed select buttons are pressed.

Another thought...

Infeed guide shuttle direction changes could be handled with simple limit switches, or limit switches tied to a material diameter-dependent offset.

i.e "reverse direction N encoder counts after switch 1 goes HIGH". , and N is a variable based on material diameter and some experimentation.

The guide feedrate should be user-adjustable up or down (slightly) to account for inconsistent winding width due to material & tension variations.  The base feedrate would be set by the nominal diameter, and a user-adjustment made once winding starts to account for flattening/width increases once on the drum.

So the user sets material diameter and desired tension values, and tweaks the feedrate as the first couple of turns start going on the drum.

EDIT:
on second thought...

Guide shuttle base feedrate is set by material diameter, and is adjusted in steps which are based on the infeed encoder.  i.e. for diameter X, when encoder count reaches N, reverse direction.

I realized that the switches (mentioned above) are unnecessary as once you are adjusting feedrate in encoder-based increments, you can switch direction based on the same thing.

Still keep the user-adjustment, but also apply the adjustment value (or a derived value) to the shuttle direction change.

And another thought... a component to check the rate of encoder change.  If the rate changes suddenly between direction changes (new layer), it means the machine just over-wrapped an existing layer and should stop and alert the operator.  

Perhaps it will give you more information in the terminal when you start with:
linuxcnc /path/to/config/yourconfig.ini

A small chance that this has to do with Remora

sk_linuxcnc wrote:

i want the A axis to be rotating continously at a given feedrate.
and X to perform back and forth motion (based on the material width that i have, so that i can acheive a side-by-side layup of the material) the material parameters are mentioned on the above reply of mine.

Do you want A-axis/spindle rotating at continuous speed?

Or do you want it rotating at a continuous material linear speed? i.e. RPM slows down as the number of layers increases?

The few commercial winding machines I've seen appear to have torque-mode drums and an encoder on the material in-feed.  Think encoder wheel with a tire pressed against the material at the infeed guide.  I believe they are in torque mode to ensure that winding tension is constant regardless of number of wraps.

I don't know all the programming, but the infeed encoder RPM value could be connected to the drum/spindle PID to slow it or speed it up.  And the position value would be used to move the guide shuttle based on a material diameter formula.

Not really G-code stuff, more like PLC stuff.

Hi,

As long as a unsupported driver is close to a excisting driver nr, we can write some code for it so it works.
I am not very familiar with servo's, but beckhoff EL- stuff is not that hard.

Just order it, no worry's. We are here to assist.

Hi,

will this version from your repository control an real machine with ethercat servos?

You may run the machine on it, but it's not for production machine as it still has bug's.
The halcore has no home sequence etc. The version is just for testing purposes.
However i have a full backup for you, if you want to test it.

in the previous videos there was an tool direction that i could use to control the tangencial axis, is this avaliable in this version?
Yes, this works. You can simple turn it on or off as i remember.

As i am quite busy now, can we just not hack lcnc to run a axis and run blending for xyz?


 

Understood, Here's the lines where I suspect may be problematic, these are all after the touch-off:
#<touch_result> = #5063
#<calculated_offset> = [#<touch_result> - #<_hal[qtversaprobe.probeheight]> + #<_hal[qtversaprobe.blockheight]>]
G10 L1 P#<tool> Z[#<calculated_offset>]
G43
(DEBUG, Return to original tool-tip position using new z-offset: #<local_start_x> , #<local_start_y> , #<local_start_z>)
G53 G0 Z[#<_ini[VERSA_TOOLSETTER]Z_MAX_CLEAR>]
G0 X[#<local_start_x>] Y[#<local_start_y>]
G0 Z[#<local_start_z>]       <

---

LINE 244

The last line above is line 244.

The G53 call I have as -5 in my ini file. Which is an absolute call as I understand. The local variables are just that and
do not change when the sub runs.
The calculated_offset is consistent throughout the sub so that can be ruled out, I believe?
That leaves these two lines:
G10 L1 P#<tool> Z[#<calculated_offset>]
G43



 

Aciera wrote:

Not sure if this applies to your setup but classicladder does not seem to work with [HAL] TWOPASS = on

Classic ladder works on both my machines with TWOPASS = ON

2.9.3 on mill, and 2.10 on lathe.

Maybe the loadusr line needs to be in postgui.hal?

One thing to be aware of is that using motion commands with any other axis letter than XYZ causes the motion planner to fall back to one-line-look-ahead. This is not a problem if the motion segments are long enough but can cause jerky movement for short segments.

It's worth noting that immediately after the second touch-off the program aborts. There is no movement for any axis.

The read ahead will start ingesting gcode again as soon as the touch off is completed and as soon as it reaches a command that would violate a limit the program will abort. This is happening well before actual execution of the queued motion commands.

Aha, another informative data/state dump would be:

halcmd show all ini.

 

I have been running gmoccapy with a joypad with RIP tag v2.9.2 for quite a while on my mill, router, and lathe.

When I check out and build branch 2.9 or tag v2.9.3 and RIP with the exact same mill.ini, I am now getting jog Y negative direction (slow/fast) actions whenever I press the btn-joystick and btn-thumb on my joypad. I have these two joypad buttons set up to select speed (wiki.linuxcnc.org/cgi-bin/wiki.pl?Simple_Remote_Pendant).  

I used hal watch to look at gmoccapy.jog.axis.joy-y-minus and it stays false when I press the buttons. If I do use the joy-y-minus set control it jogs at the same speeds(depending on turtle/rabbit) as when I press the joypad btn so the joypad buttons seems to be triggering the jog but I don't know how this gets mapped as there is nothing in my config that did that?

Looking at my gmoccapy.preferences
use_keyboard_shortcuts = False

I had to install version 4 of gtk something to get v2.9.3 to run, now I can't run run 2.9.2 anymore. 

Any help/hints would be appreciated.


 

Agreed on the "probe succeeding".

I added this in order to see what is taking place:
'Return to original tool-tip position using new z-offset: ...'

I've noted from the script that:
#<touch_result> = #5063
which equates to 277.16xx in this case. Fairly consistent thru the 3 attempts.

I'm attaching the script as I have it now including the extra debug messages.

It's worth noting that immediately after the second touch-off the program aborts. There is no movement for any axis.