GearHeads Corner
March 19, 2019, 09:50:28 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
 
   Home   Help Search Login Register  
Pages: 1 ... 6 7 [8]
  Print  
Author Topic: reading Pokeys pins  (Read 1444 times)
0 Members and 1 Guest are viewing this topic.
gburk
Jr. Member
**
Posts: 64


View Profile
« Reply #105 on: March 15, 2019, 10:06:55 AM »

Art

>This is on the work coordinat es tab right?
>Not the machine coords tab? Sounds like we're close anyway...

Yes word cords,
also I don't think I can read the mach cords in a script I think I had said this one before

if I use gettruepo s not sure if command is correct don't rem off top of my head but it returns the same value as the getaxispo s work cords ,,

I will try slowing probe down, and or a higher accelerat ion..

when probe is it are you returning the probe position with a call, or just using getaxispo s?,,
 

Thanks gary
Logged
ArtF
Administrator
Hero Member
*****
Posts: 5183



View Profile
« Reply #106 on: March 15, 2019, 10:31:31 AM »

Gary:

 I should have mentioned, I fixed also the GetTruePo s() to give you back the machine coordinat es.
When you probe, if it hits the end position is the actual stop position not the probe position.
 To get the probe hit position, you call GetGlobal("ProbePos0"); (for x)

  After the axis has decelerat ed, the planner position is set to the last position of actual motion.
If you wish to go to the point it hit at, you should be able to do a g1 move to the ProbePos0 in
your case. Take note the probe may or may not unactivat e as that point in space will be the trigger
position of the probe switch so various factors may make it too close to release.

  It sounds to me like you may be hitting some sort of race condition where the last coordinat e
hasnt updated to the planner before calling for the G1 after the probe. You might want to add
a yield(); just before the g1. A yield is just a way of lettign auggie catch up with any tasks its
doing so if one suspects your going to fast in commands, a block for "motionsti ll" or a yield()
is a good way to make sure things sync up.. It may not help, but as I found mine to be accurate
each time I think it may be the speed of my system vs yours perhaps. This type of thing is hard
to find  but there are many threads running doing various tasks so I worry about syncing at
times , and a yield may help.

  psuedo code example..
{
   Engine.GC ode("G31X10F50");
   block("MotionSti ll");
   if( GlobalGet("ProbeHit")
    {
       yield();
      ProbePos = GlobalGet("ProbePos0");
      Engine.GC ode("G1X" + ProbePos );
      print( "Probe Successfu ll. Zero Me.");
   }
   else
   {
       print( "Probe Failed.To o far away, zero me and try again.");
   }
       

}


Art


Logged
gburk
Jr. Member
**
Posts: 64


View Profile
« Reply #107 on: March 15, 2019, 10:58:40 AM »

Art

Set the probe speed lower and its a lot better, should be good enough not to go way past the end stop..

You are mostly right the system is not updated fast enough now that the probe is running slower, I can see it better looks like if probe is hit at -0.430 or so when I do a g1 x1 it retracts to +1.4 or so for some reason it seems to be adding the current pos to the 1 for retract make sense ?

will test the new stuff..

tested you code work good but I added so to set axis to .250 and the retract to 1 but still go's past one to 1.3 or more heres the code maybe I am doing something wrong still added another yield for testing but made no differenc e..

also looks like gettruepo s is working now.

   GlobalSet("ProbeInve rt",0);
  Engine.GC ode("G31 X-3 F10");
   block("MotionSti ll");
   if( GlobalGet("ProbeHit"))
    {
     yield();
     ProbePos = GlobalGet("ProbePos0");
     Engine.GC ode("G1X" + ProbePos );
     block("MotionSti ll");
     xpos = Engine.Ge tAxisPos( 1 );
     print("Probe Successfu ll. Zero Me. "+xpos+"  probe pos "+ProbePos);
     Engine.Se tAxisPos( .250, null, null, null );
     yield();
     Engine.GC ode("G1 X1 F50");
     block("MotionSti ll");
   }
   else
   {
     print("Probe Failed.To o far away, zero me and try again.");
   }
     
 
Gary
 

Gary 
« Last Edit: March 15, 2019, 12:15:12 PM by gburk » Logged
ArtF
Administrator
Hero Member
*****
Posts: 5183



View Profile
« Reply #108 on: March 15, 2019, 01:16:41 PM »

Gary:

  Try this script for me. I ran it several times with probe hit and no probe hit, it returns to X=0 every time.
Id like to know if your does different . There's a bit of a dance going on when a probe is hit. First, the program stops motion.It clears the planner of any subsequen t moves. It then flags the system to refresh the planners current position to wherever it stopped. The next move in the script is to move to x=0.

   Now if the move to x=0 happens before the probe internals have reset the planner, it may still think its at
the last commanded position, which is the norm. This means if the probe stopped you at x= .5, but didnt set the planner to .5, it will still think your last move ended at X10, or whatever the stop was. So a move to x1 may move 9 units up. But if the planner knows it stopped at .5, then it should move only .5 to get to zero.Your symptoms seem to show its stopping on the probe, but not resyncing to the actual position the
machine coordinat es are now at. Im just not sure why mine works..bu t perhaps both of ours work
on this script but fail on yours. Let me know what this simple script does..



Engine.GC ode("G31X10");
block("MotionSti ll");
if( GlobalGet("ProbeHit") )
{
  print("Probe was hit");
}
else
{
 print("Probe not hit");
}
Engine.GC ode("G1X0");

  Does it always end at x=0 on the work coordinat e display?

Thx
Art

Logged
gburk
Jr. Member
**
Posts: 64


View Profile
« Reply #109 on: March 15, 2019, 06:54:33 PM »

Art

ran the script 10 or 15 times let it run to end 5 time always returned to 0, hit probe at different distances and always returned to 0

then added the line to set axis position to .250, let it run to end g31x10 then set the position to .250 so now axis position is set to .250 and then the g1x0 runs  but go's past 0  to -9.9498.

so far as I can tell right now its good endless you reset the work position from where it stops. does the same thing if you hit the probe but stops at different - positions I assume it reversing to the - value from the probe hit so if I hit the probe at 3.467 when  axis reset to .250 it travel's to -3.467 not exactly the back distance but in the area
 
hope this helps a little
 
thanks gary
Logged
ArtF
Administrator
Hero Member
*****
Posts: 5183



View Profile
« Reply #110 on: March 15, 2019, 07:16:23 PM »

Gary:

 Thx, that points to the error, I must not be resetting the planner after the scripted Axis position
set. Ill fix that up. Thx for your tests, when I wrote Auggie I put in a lot of code that has never
been tested, I added it just in case. Much of this problem seems related to simply being
untested code.  Comes from writing a controlle r in a year. Smiley

 Ill let you know when the fix is online.

Art
Logged
gburk
Jr. Member
**
Posts: 64


View Profile
« Reply #111 on: March 16, 2019, 08:35:19 AM »

Ok thanks

Hopefully you have some code to read the encoder pins13  I would like to be able to setup the pin for spindle index  1 rev per if possible.
and also be able to  use pin17 for pwm output 0-10v for the spindle speed  control.. but first things first lets get probing going first..

I know I keep bring this up but is there a way to get the global script running so I don't have to run it first in the script edit then use the button.

Thanks gary
Logged
ArtF
Administrator
Hero Member
*****
Posts: 5183



View Profile
« Reply #112 on: March 16, 2019, 12:17:11 PM »

Gary:

  I believe you can poll the encoder counts from the pokeys, but I dont think you can
the index. Ill have to look up what informati on the pokeys sends back on that.

  You can use any PWM channel you like. Examples of that are in the laser control
library as I use that library to control pwm power for the lasers.

 As to the problem with the script having to be run before the button call to it will
function, Im still not sure whats going on there. I'll take a look to see how one of mine
works and perhaps we can figure why yours doesn't mimic it..

Art
Logged
gburk
Jr. Member
**
Posts: 64


View Profile
« Reply #113 on: March 16, 2019, 04:03:24 PM »

Art

I don't own a laser so that Greek to me right now...

I did look at the laser lib didn't see anything for pwm only turning on and off relays for air blow…

looked in the gcode lib that had some on pwm spindle speed don't look like its functiona l and looks like you need a real high spindle speed over 25000 to get it to return a value other than 0 not sure on how you are sending the pwm pulse. I'm used to just sending m3 s3600, or similar. right now I do have m3 and m8 working for turning on the spindle relay and coolant and m5 and m9 to turn off relays.

I thought I read some where that you are using motor 8 for laser control, I may be wrong.

I think pin17 is just a pwm pin for 0 to 10 v output I tried setting pin17 but haven't any luck changing the voltage output...

But this is a later problem  Undecided

One thing at a time first probing, we are almost there, just a couple things not quite right, but I know you will get it...

Gary
   
Logged
ArtF
Administrator
Hero Member
*****
Posts: 5183



View Profile
« Reply #114 on: March 18, 2019, 04:44:11 PM »

Gary:

 Just uploaded a new Auggie that should rest the planner after you use SetAxisPo s so that
subsequen t moves do not overrun. Let me know if this fixes the current script problem.

 I use motor channel 8 for realtime pwm control, but this isn't how you'd do it for a spindle,
in that case youd call the PWM script calls to set up a channel , a base frequency and an output
level. We'll go into that after this probing is all settled..

Art
Logged
gburk
Jr. Member
**
Posts: 64


View Profile
« Reply #115 on: March 18, 2019, 07:35:26 PM »

Ok will test it out

I think the PWM channel is 5 if I'm reading things right but after probing is going...

Gary
Logged
gburk
Jr. Member
**
Posts: 64


View Profile
« Reply #116 on: Today at 07:29:14 PM »

Art

Here is some numbers I am getting all are with g31 x-3 and retract after probe is hit I set the axis to .250,  then do a g00 x1

Probe run started at 0  - hit at -.3955  reset to .250 retracted to  0.6255           - started at positive hit at negative ended at positive
Probe run started at .6455  - hit at -.3802  reset to .250 retracted to  1.2758     - started at positive hit at negative ended at positive
Probe run started at 1.2758 - hit at -.2863  reset to .250 retracted to  1.8120    - started at positive hit at negative ended at positive
Probe run started at 1.1820 - hit at +.5002  reset to .250 retracted to  1.5681   - started at positive hit at positive ended at positive

Seems close to before I think is there a way to tell if the version of auggie has changed.. ..

I thought I left a message last night about this but don't see it, that's a good thing I was having all kinds of problems last night
estop getting triggered off every time I had the line to setaxispo s(.250) in the code, if I removed it all was good, now decided to try again tonight and I don't seem to be having the problem maybe I was having a computer gulch …

looked at the way I have mach4 setup for my spindle I am using ob5(10) step/dir and ob5(10) set to motor5 with the smoothste pper


Thanks gary

Logged
Pages: 1 ... 6 7 [8]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!