Eric:

In case you missed it - check out reply #318. Art issued 1.15
It works good too.

Sage

Hi Art:

You will remember I mentioned that my Y-axis homes in the full Y+ position so I set the Y offset setting  in Mach to 6.4"
and I commented that 6.4  never shows up in the DRO in Mach4 after Ref All Home  like it used to in Mach 3. In M4 the DRO just stops at whatever count happens to be on it when it stops.


Last night and this morning I notice the 6.4" is now showing up in both the machine co-ordinates display and the other DRO (sorry I forgot the name of the standard DRO).

I have to admit that it's not exactly 6.4" it has some error (actually 6.4063 or something like that).
Any idea what changed? I haven't touched any settings in the last few days.

I believe you said the rest of the homing procedure (final positioning and DRO display etc.) was going to be up to a user program. Has something changed?

Sage

Sage:

  No. It all simply depends on where you were zeroed before homing. The DRO that gets changes is the G53 machine coordinates. If your current work cooridnates are the same as the machine coordinates, then it will look as if both are being set to your offset. But if their different, the numbers on the DRO
in work coords will not change, provided they were correct to start with. Play around with zeroing in variou sspots and them homing and it will become
apparent as to whats going on. Darwin only sets the machine coordinates after a homing, and it only sets them to the actual distance to "home" which
you describe with your offset as being a set distance form the home switch activation.

Art   

Hi Art:

I'm going to have to investigate this more. This morning when I started up the table was only about halfway along in it's Y travel so I'm going to say about 3" from the switch. I didn't notice what the DRO's defaulted to when they came up (I would resume 0.0 but maybe not). First thing I did was a Ref All home. So I assume the Y would have moved only 3" to the switch. So the one DRO would only read 3".
 It would be a BIG coincidence if the starting position of the table in Y plus the value that defaulted on the Y DRO's added up exactly to 6.4xx to be exactly the same as the machine co-ordinates display.

I'm sure I'm wrong on all this because you know how it all works. I'm going to have to try it a few times and take some notes.
Maybe I was looking a the machine co-ordinates display and I wasn't toggling it properly to the other display. (so assumed they were the same).

Thanks.

Sage

Hi Art:

See previous post as well.

I tried this all again. Here's the findings.

In case I'm confused with the DRO's names. Work co-ordinates is the "normal" display and Machine co-ordinates are the ones you have to press the button (till the led is lit) to see the display.

With M4 still running from my previous session. I homed the machine so Y was sitting on the Y home switch.
I zeroed the Work DRO and  jogged Y to 2.5" off the switch so I now I know how far it has to go back to the switch.
I shut down M4, waited and restarted it. The Work Y display got loaded on start up with 6.4065 on startup. The machine co-ordinates display was 0.0 on startup.

I zeroed the Work Y DRO so now both machine co-ordinates and work co-ordinates DRO displays are 0.0. I still know the table is 2.5" from the switch.
I pressed the Ref All Home button. The work co-ordinates Y display counted to -2.5 and when it got there it immediately  changed to 6.4065.
The machine co-ordinates display was now also 6.4065

Other than it's 6.4065 rather than 6.4000, I like it this way because it's displaying pretty close to where the table actually is. Like it did in Mach3.

So what am I seeing / doing / interpreting wrong?
Perhaps nothing as Darwin is acting as you programmed it and Mach4 is putting the offset on the Work DRO as it was asked to do.
My confusion comes because it wasn't doing this (or I didn't notice it) a couple of days ago.


Sage

 Sage:
   
      This is a question of understanding machine and work coordinates.
      Your work coordinate displays the distance from the last zeroed position. So in your case you zeroed
      the Y work coordinate when the machine coord was 0.
      So the work coordinate and machien coord read 0 together. No now you home, when the switch was hit
      the Machine coordinate got set to your offset, in this case 6.4065 , the extra being the distance the
      axis took to declerate after hitting the switch. That machine coordinate reading at that point then
      is the distance from where your currently at..to what your machine considers "Home" for the Y axis.
     
      Now the Work coordinates instantly changed as well, because its job is to report how far it is
      from the last zeroed position. The last time you zeroed you were equal to the machine coordinates.
      So when the machien coordinates changed, your work coordinate display had to as well. Your work
      coordinates now have to display the distance to the machine coordinate of 0, which you zeroed it to,
      so it now displays 6.065 as well. Had you zeroed at a machine coordinate of 10, your work cordinate
      would have changed to 16.065 .. 
     
      Consider this as an important feature for checking accuracy.. Lets say you zeroed in the middle
      of your table for a job. Half way through you suspect you lost steps. So you hit pause. It stops at
      a reading of 2.345 on the Y. You note the position and hit ref all. If the system homes and the machine
      coordinates are accurate ( you havent lost steps), you will not see any change in the work coordinate DRO's
      when the switches are hit. This is beacuse the machien coordinates didnt change, they were and stayed
      accurate. BUT, lets say you hit soemthign in the job, and you Y is .5" off. SO when the switch gets
      hit the machien coordinate zero and changes by .5, ( the distance it lost since last home). As it changes by
      .5, so too muct your work coorindate in order to repair the lost units. SO now you command it to
      go back to 2.345 where you pasued and youll notice your now .5" away from where you paused. You have
      repaired the lost steps. The rest of the job will now be accurate. Homing is good not only for starting a job
      over bu t for verifying that you have lost steps, just home and see if the DRO changes, if it doesnt you
      were accurate, if it does, you were off, but no longer are.
             
      I dont know why the guys dont have it startup with the last known coordinates, it can probably be
      configured to do that, but thats out of the scope of the printer port itself, more a question of
      how mach4 works.. and Im woefully inadequate to that task. I havent used Mach4 other than to code up
      a plugin for it. I will be designing my laser engraver aorund M4 so over time Ill know more about
      its care and maintenace.. and probably figure out where to set startuyp behaviour. , but the best
      best for any machine with home switches , is to do a refall immediately after every startup..and
      whenever you think perhaps youve lost steps..
     
      Art
     

Art:

Thanks for the explanation. It makes sense now. If this is the way it has always been then I've apparently been missing a pretty useful feature. I'll have to test the repeatability of my switches to see if they are accurate enough to use them the way you describe they are supposed to be used. Right now, when I think the machine has gotten out of calibration I go back to my 0,0 point on the work but then I have to change to an edge finder or center finder to see how far off I am. Being able to use the switches and 'test' my position without disturbing anything and have it correct itself would be really handy.
I guess I've learned something. I try to do that every day.

Sorry to make you explain all that twice. But I think I get it now.

Thanks

Sage

No problem. . took me a few times.

Art

Hi Art,

I know my problem with the duplicated inputs will probably not get much attention until someone else sees the same problem or the more pressing ones get solved.  I understand.
I have been updating M4 and Darwin as new versions become available in the hopes that the problems will go away even though they are not specifically mentioned in the changes.  However, I still have port 2 inputs 6, 7, and 8 being replicated on inputs 12, 13, and 15.  In addition, input 9 is replicated in inverted fashion on input 11 and the actual input on 11 is not recognized.  I have also noticed that the DRO for encoders 1 and 2 seem to count up and down as expected, while the DRO for encoder 0 only alternates between 0 and 1 as the inputs are triggered.

Is anyone else using port 2 for inputs?  Encoders perhaps?  A probe?

Regards

Peter

Peter:

 Actually, Ill try to figure this one out again now. If you switch port 1 and port2's port addresses, does Port1 then show the same thing? ( or do you know).

 It may be any port with 2-8 as input ends up mirroring into the upper bits. Ill try it tomorrow and see. Hopefully I can repeat it..

Art