Hello Guest it is April 18, 2024, 03:06:46 PM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - JimKnopf

Pages: 1 2 »
1
General Mach Discussion / Re: Homing position is not absolute
« on: May 05, 2011, 03:18:27 AM »

Which, BTW, will be exactly as accurate as setting the zero when the switch actually opens.  The number of steps the machine takes after the switch opens will be exactly the same, as long as the home velocity and acceleration do not change.

Regards,
Ray L.
Hi Ray!

And here you see one point. I don't want to be fixed on the speed and acceleration settings while I may improve my machine. That's the one thing. And the second, if you are closer to the switch as needed for accel to full speed, you will get different results. That is simply not perfect but easy to change.
I got a very fast answer from Andrew. He will think about changing the code and if he does it may not stand at the top of his list.
He advised me to use a macro, and I'm going to write one but I first have to learn more VB and how it is working with Mach3.
Here is the structure I will follow:

struct x (homingDir,homingSpeed,maxSpeed,resolution,signal,homing button)
struct y (homingDir,homingSpeed,maxSpeed,resolution,signal,homing button)
struct z (homingDir,homingSpeed,maxSpeed,resolution,signal,homing button)
struct u (homingDir,homingSpeed,maxSpeed,resolution,signal,homing button) //universal
//reading the homing config
set the variables with the values in the config

//reading motor tuning config
set the variables with the values in the config
//reading ports and pins config
set the variables with the values in the config
x(homing button) =1022
y(homing button) =1023
z(homing button) =1024
u=z //copy the set of variables
do homing
reset coordinate
u=y
do homing
reset coordinate
u=x
do homing
reset coordinate

End program

subroutine homing

while u(signal)// make sure the switch is released
   move axis inverted(u(homingDir) about u(resolution)
end while

dooembutton (u(homing button)) //to get fast to the switch or something to make the axis move til the switch is hit

while not u(signal)// closing the switch
   move axis u(homingDir) about u(resolution)
end while

while u(signal)// release the switch
   move axis inverted(u(homingDir) about u(resolution)
end while

move axis inverted(u(homingDir) about 1mm //clear jitter area
end subroutine

I don't know if the function struct is part of VB, and if it is possible to get the value of the switches.
With this macro the homingpoint will never change unless you change the resolution of your axes.

I even don't know if it is worth the time and power to write such a macro.

Burkhard

2
General Mach Discussion / Re: Homing position is not absolute
« on: May 04, 2011, 03:52:12 AM »
Hi All!

Thanks Hood for the link, I've send andrew a mail.

Thanks TP for confirming ;)
Thanks everyone for your suggestions and advises.
Now I will wait if I can get an answer from Andrew.

Burkhard

3
General Mach Discussion / Re: Homing position is not absolute
« on: May 03, 2011, 01:35:41 PM »
Hi Ian!

Thanks for the explanation, now I know about CV :-). Your Deutsch was perfect :)
I will increase my acceleration, when I finish the new drive circuit wit FETs. But I will drill and engrave the PCB with my machine ;-)

I just thought that the way of the homing with dir/step controlled steppers could be improved. I will write to Andrew when I get the email address.
Burkhard

4
General Mach Discussion / Re: Homing position is not absolute
« on: May 03, 2011, 06:39:01 AM »
Hi Ian!

Now you got me :)
I'm not familiar with all terms, especially in English. What means CV. I'm now ready with my second machine. The first one was build of wood :D. And it was working. Not very stable but OK for PCB milling. I was using cheap materials like "trapeze" screws. Now I'm using quality components, like supported rail, ball screws.
The only things missing now are the limit switches and the toolsetter.
Basically I can live with the effect I described, because I know how to prevend it. But I think it will be simple to change the code in the program to avoid these things.
Burkhard

5
General Mach Discussion / Re: Homing position is not absolute
« on: May 03, 2011, 03:09:26 AM »
OK JUst a question are we talking PP or SS??  (;-)  I do know that homing is control through the driver on the PP.  SS??? should be on the board.

(;-) TP
Hi TP!

I have a very simple machine, self constructed. I use stepper motors (dir/step controlled) using the parallelport. The homing sequence is full controlled by Mach3. The optos are connected to the parallelport.

It really would not make sense to do it any other way.
That is what I mean, but it does not work that way.
It is so easy to test, I can only repeat it. As long as during the homing, a acceleration curve take affect, the machine will travel on after releasing/leaving the switch. You can see, that the machine doesn't travel towards the switch again. Look at the machine coordinates. If they show zeros that will be ugly, and that is what I see on my machine. And it is not to clear the jitter area.  It is not the speed of the parallelport it is the software.

@hood
that was the first thing I wanted to do, but I did not find an email adress.

Burkhard

6
General Mach Discussion / Re: Homing position is not absolute
« on: May 02, 2011, 02:29:52 PM »
Really though you don't have to find the best speed, you just have to use one and not change. Granted if you have slow accel and are closer than your axis can accel to full speed then that distance may change but the double homing should prevent that being an issue.

Hi Hood!

You are wrong!
If you are to close to the switch (closer than the distance needed to accel to homing speed), the axis stops exact at the same distance from where you started, because the accel and break distance are the same. You can do the homing 10 times. If you are to close at the first one, you will be also on the last run. I have tried it!

Do the homing from a distance. Watch the stepper position. Make a very littel move towards the switch without activate it. Do the homing again. You will see, it will be a different position. Do the homing again and you will get the same position as the last one.

If I optimise my stepper driver I want to increase speed.

Burkhard

7
General Mach Discussion / Re: Homing position is not absolute
« on: May 02, 2011, 01:44:22 PM »
Hi Ian!

Thank you for your explanation! That's exact what i mean, and that is what I don't like. It would be really OK if the point of releasing the switch is recorded and after that the machine comes to stop. The coordinates displayed then would not be zero but the distance D. That would be always exact :).
I find it annoying to need to search the speed with no acceleration curve, if it is possible. I think that is the job of the program. Like I said, moving back step by step.

@BR549
It is so easy to test. Set your acceleration on a low level, 10 for example. Move away from the switch and do the homing. You will see what we described. And look at the diagnostic page, you will see the machinecoordinates are set to zero where the machine has stopped. If you where right the distance from the switches must be displayed.

@hood
I set the acceleration to 40 for testing. That is not what I will later use, but why do the user have to care about these things?
There is another possible problem. If the switch is released before the machine stops, it won't move back at all. As I said, I used light barriers with a small pin moving thru the opto ( in fact a needle). That doesn't work, I have to use a thin plate. I think good code should handle that (if switch is released before coming to full stop, move back first til switch closes again and then expect the release).
I don't like to have to find the best speed for homing. That's the job of the program. Why should I travel with 10% of the speed across the table when only 3mm are needed.

Mach3 is a great program, but homing is a fundamental function that should work perfect I think.

Burkhard

8
General Mach Discussion / Re: Homing position is not absolute
« on: May 02, 2011, 09:46:07 AM »
My variances are about 0.1 mm with low acceleration

9
General Mach Discussion / Re: Homing position is not absolute
« on: May 02, 2011, 07:33:28 AM »
...
 so I concluded that it was repeatable.
......


Hi!

I think it is absolut repeatable, as long as you don't change the speed and ensuhre, that the axis always reach the maximum travelspeed (means minimum distance from the switch/optos).

Burkhard

10
General Mach Discussion / Re: Homing position is not absolute
« on: May 02, 2011, 04:59:07 AM »
Thanks Ian for confirming my observations!

I also use CNC-Player and that program do the homing the way you mentioned. But it only uses the moment when the switch is hit. There are fields for hysteresis (distance between closing- and openingpoint of the switch) and the distance to move the switch free. hysteresis is not needed in Mach3.
I  think the only constant position will be taken, when the releasepoint will be found without an acceleration curve. I have no problem when the machine travel an extra distance (may be 1mm), if it will allways be the same. The optimum would be to run with max speed into the switch, move back step by step til switch is released, reset the coordinates and travel on a defined distance ( or first travel on and reset coordinates on that position). This will be fast and absolute exact. May be something like that could be inserted in the program code.
@Gerry
Is it possible to turn off/on limitswitches inside a macro?
Burkhard

Pages: 1 2 »