Advanced Search

Perhaps a typo or a space in the folder name why it didn't work before, but if it works in this folder it's alright. Yes the firmware supports 6 axis, it can even be set to 8 axis in the firmware and component.
The firmware cannot see if there's a motor connected, so that's not the cause.
Possibly you didn't upload a config to the nvem yet? Otherwise you might use the wrong component. To see if the config is uploaded correctly you'll see that on the uart output.

I noticed that the following code appears well into the SUB:

o300 if [#<_hal[qtversaprobe.enable]> EQ 0]
   (MSG, Auto Tool probe disabled )
    G43 ;turn back on tool offset mode before returning
o300 return [3] ; indicate no tool measurement
o300 endif

Actually, after the first M6 in the code. If I'm reading this correctly, the IF statement gets evaluated when TRUE.
If this is the case then why would it not be at the very top of the SUB? The reason I ask is because the line above this block is a 
call to G49 which cancels tool length compensation. Meaning why bother to even begin the sub if it's not enabled?

That said, this return code of 3 shows up as the abort parameter in both of the failures.

Any feedback or thoughts what-so-ever are encouraged.   
 

If anyone is looking for information about the EZ Trak DX II, I have one with all the original manuals and schematic.
The PC based controller is slowly dying though so I'll be converting it to LCNC in the kind of near future.

thank you very much Roy, it is not able to start, it reports that it does not find the ini file even though it is there in the config/remora-nvem folder.. I managed to start it by transferring the files from the remora n-vem folder to the sim-config folder. it wants to start..it reports a joint following error, but this is probably because no any motor is physically connected, no is the set scale etc. changed. my question is, does the firmware support 6 axis even though it is factory nvem2-4axis version?

Looks like i can use A axis rotary moves with the grinder spindle on Z with A being aligned on Y to create Gcodr 

Awesome, that did the job!

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