Advanced Search

Spyderbreath wrote:

Warning: Spoiler!

At the risk of the blind leading the blind, to me that is not quite the right question. That chart is for your micro-stepping. Like the 800 is 4 microsteps, if you're using a 1.8 deg. stepper. I have always looked at it this way - What are you doing with the motor? If your opening a door or driving a ram, picking 800 would be fine, but using that on a belt or lead screw may very well end up leaving artifacts in the work due to the rougher movement between points. The downside is the more micro-steps you have the more torque you lose. 3200 (16 micro-steps) seams to be a reasonable middle ground that most use as standard. The controller will put out as many steps as directed by LinuxCNC to make a revolution, just a matter of how fast it can do it.

Whatever you chose, that gets figured out when you tell LinuxCNC in your .ini file how many pulses it takes to move one unit. That is set with the SCALE on each axis. Like for me, I have 16 micro-steps (3200) and a 5mm pitch screw, which works out to SCALE = 640 or -640 depending which way you need the motor to move.

I wanted to give it a high pulse/rev value to have a higher resolution, but I couldn't get precision in long movements. I put your values ​​and after a slight change of scale everything went well!

Thank you very much.

Isn't there a way to calculate SCALE in a precise way? Unfortunately the seller of my steppers and Drivers doesn't give me datasheets and it's really difficult to set them up properly, except trying random values. I also tried with math but nothing I couldn't get low error values ​​Scale=scale_set*Dist_measured/Dist_Insert

DarkPhoinix wrote:

is there a way to download previously uploaded nvem-rt1052.txt from NVEM?

 
Unfortunately, no. It's a one way process.

JPeters wrote:

Hello scotta,

thank you for your quick reply. Yes, that is exactly what I thought myself.

The EC500 is powered by an external power supply. From the 6 pin header, GND, SCK and SDO have been connected to one of the probes.

I don´t have any kind of schematic on hands for the EC500. So I am not shure, why the header pin is labeled SDO. I would expect SDIO for a sufficient SWD connector. Is your header labeled with a SDO too?

My EC500 is labeled with IMXR_EC500 2023-05-18

Up to now, there has not been a single successful flash. From within MCUExpresso, I am at least able to build your application.

If this is not going to be successful: do you think, your actual project with W5500 and raspberry pi pico is as powerful as the 1052 solution and could be a viable alternative?

Thank you very much. I will try to give more details tomorrow.

Cheers Julius


 

I'll need to check the labelling on my boards. With MCUExpressoIDE does it report an error when trying to connect. It may give some clues.
Remora supports quite a number of 3D printer boards. The EC300/500 being 24V IO is more suited when using industrial hardware.

Yes. Good catch.
I would still appreciate knowing how to call anyone of these routines without going through the entire program. Also how to set the Z after the tool change.

Thank you

Aren't you missing a 'CALL' in line N15082:
 

I have attached my progam with subroutines and cut out much of the program inbetween.  I begin by "homing, clearing all offsets (G10 L2 P1,2,3,4,5,6), G92.1.
Then I load my program which contains 3 subroutines.  My tool position at start is program 0,0,N) N being the top of work what ever the program subroutine calls for.
Hit run and it works beautifully.
Next Engrave operation calls for a tool change and change of Z offset.
This is where it all gets lost.  I change the tool and position it, set g54 Z offset and it takes off for the last G57 position.
Don't honestly know what I am missing.
Also would like to be able to call one of the subroutines out of order and be able to run it.

Thanks for any help in advance
I am determined to get a handle of these subroutines.  I know I'm missing something here. 

If you  scale has periodic index marks you need to coarsely position
the axis before the final home to index (this is usually done with a home switch
but could be done by jogging to a mark and then homing to index)

Ok! I'm really a beginner at this...

My machine homes and the dro goes green on all axis Problem is that it seems to be doing so on some kind of periodic index from the scales, so after homed it has no idea where along the scale it is at the moment... must be missing some important lines in my configs.

I really don't get the dev's why they stay using .comp code, and even worse: promoting it to use.

Nobody is forced to use it. I like the 'comp' format and I do promote it. The point is that it lowers the bar for people who are not C developers to create their own components. There are a lot of components (possibly even 'cia402.comp') that would not have been created if that tool did not exist.


Note that the 'halcompile' tool will actually create a .c file from a .comp file for you, if that is what you want to work with.
linuxcnc.org/docs/html/man/man1/halcompile.1.html

This solved my issue, you saved me a huge headache thank you!

RotarySMPs hal/ini files are from LinuxCNC 2.7 or earlier so before the
AXIS/Joint separation change.

Newer hal/ini files like yours put the homing ini constants in "JOINTN"
sections

I checked the userkins.comp file, found nothing strange, but in userkins.c, it was

int kinematicsForward ...
   ...
    pos->tran.x = j[0]/80; // X coordinate
    pos->tran.y = j[1]/80; // Y coordinate
    pos->tran.z = j[2]/80; // Z coordinate

while in userkins.comp or either of the kinematicsInverse functions, the /80 was not there. I tried compiling again, nothing changed. I tried deleting the /80 from userkins.c, everything is now working. I just have no idea why..

We moved to Ingleburn, not far from Campbelltown, in the very late 70's. At the time they were building a lot of housing commission places, the joys of coming from a "broken home", anyways all the building was causing the snakes to look for new places. Usually the first sign you got was the 2 dauschhunds going off their heads, and sure enough there was some snake or another making themselves at home.
Funnily enough the worst incident we had wasn't a snake bite but 2 of the neighbours' boys decided to sniff glue and start taking shots at each other with slug guns.
"But dad I only shot him in his glue"

On there was also the mattress fire under the house due to one of the neighbours and his girlfriend smoking and having a pash session.

And no I was only 6 or 7 at the time, we were just general menaces, favourite was running through the pond outside the doctors surgery. 40 years later I was working at the railway station when they were doing upgrades at Ingleburn, and yep the doctors surgery and pond were still there. I thought about it, but too many aches and pains to run through it, plus it was pretty cold that day.

Hi Hakan,

At the moment it's here.
But i can not help you with questions at the moment as i have not reviewed the code for a while now.
The ethercat-master is also there. It has different source code to store the xml in memory.
However i think it will run.

I just conversed the cia402.comp to c code .
I really don't get the dev's why they stay using .comp code, and even worse:  promoting it to use.

do you mean for a spindle? haven't looked at it yet.
i would be surprised if servos have velocity control... or do they?