Hello Guest it is April 24, 2024, 12:32:57 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 - DaveCVI

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 »
291
CVI MachStdMill (MSM) / Re: Tool Table Report
« on: August 09, 2010, 02:22:46 AM »
Tom,
Good news: the TT report is still filtering out empty tools...
Bad News: The sample tool tables got clobbered and have all tools marked as "non-empty".
 (so the report shows them all).

I've fixed the tables and the cause of the problem for the next release.

In the mean time - you'll have to edit any existing tool table description to mark the tool(s) you don't want in the report as "empty".

Sorry about that...

Dave

292
CVI MachStdMill (MSM) / Re: Can't return to TCP
« on: August 08, 2010, 02:23:50 PM »
Calum,
Given the time zone difference between us, I tried to go ahead and email a patch to you via direct email.
Alas, the email address your user account name shows, bounces with and unknown host error.

PM me with a good email address and I'll send the patch to you.

Dave

293
CVI MachStdMill (MSM) / Re: Can't return to TCP
« on: August 08, 2010, 11:23:21 AM »
Does this happens when you try to use settings-common page, "Set TCP TP MCz"?

Please confirm that this is where you get the MSM message re not at TCP.

Within that routine I see a bug in the code - two sets of registers are compared for being within a tolerance vlaue - but I forgot to scale the tolerance value for in vs mm  machines  ::)

Once I know that is the context for the issue, I can build you a custom probing lib. That will get you running until the fix shows up in the next release.

Dave

294
CVI MachStdMill (MSM) / Re: Can't return to TCP
« on: August 08, 2010, 02:11:54 AM »
0.0188mm is not very large -
What's the distance of a single step on your machine?
Is this an integer multiple of a step?

Dave

295
CVI MachStdMill (MSM) / Re: Can't return to TCP
« on: August 07, 2010, 11:09:23 PM »
Calum,
I haven't experienced this.

1) Are you remembering that TCP is always in MCs?
Are you maybe looking at a current position in WCs  and wondering why it is not the same as a MC value?

2) Put the current Position panel (to the left of the TCP panel) in M-Coords (MC) mode - now you can see the current MC position next to the TCP (in MCs) position.
click "Go TC Pos'n"
When it stops short are the MC DROs different from the TCP DROs?

3) The core of the GoTo TCP button is pretty simple and uses G53 to go to the TCP; and the TCP is just the contents of the TCP DROs you see on the tooling page.
If the curr position DROS (In MC mode) are not at the TCP when motion stops, that is very weird.
Something has to be stopping mach's motion... So let's think about what could stop mach from getting to a commanded position -

Soft limits? Are they stopping you from getting to the TCP?

4) Are you running 3.43.10 or 3.43.12?
have you tried a mach reinstall?
(as an experiment, I'd just install mach on top of itself to see if it makes any difference).

Dave

296
CVI MachStdMill (MSM) / Re: Homing and Limit Switch Probblems.
« on: August 07, 2010, 11:36:32 AM »
Eric,
It's good to know you have it working now - have fun!

Dave

297
CVI MachStdMill (MSM) / Re: Homing and Limit Switch Probblems.
« on: August 07, 2010, 11:12:03 AM »
Good to know that we have identified what the problem was.

Here is some info re debouce:
4000 is a pretty high debounce setting.

Mach's debounce is really a software fix for a hardware problem.
The ideal solution is to remove the noise form the system and use a debounce of 0.
Many people either can't or don't want to expend the effort required to accomplish that.
The pragmatic approach is to lower the debug number until the problem reappears, then raise it back up a little.
That leaves the issue of "How do I tell if my required debounce setting is too high"?

"Debouce" is the amount of time a signal must be continually "on" before mach will consider it as just having turned on.
Each number in the DRO represents about 40usec of time (25kHz Mach: 1/25KHz = 40uSec)
A debounce of  40uSec* 4000 = 160mSec. That is a long time for a computer, it's even pretty noticeable to a human.

At 4000, the probe signal has to be on for a minimum of 160ms before mach will see it and stop the probe motion.

How fast are you probing?  Let's just pick a number for illustration:
Say you are probing at 50ipm; during the debounce interval the probe will have moved (50ipm * 160msec ) / 60 sec/min = 0.133 inches....
so the probe will travel 0.133 in past where the edge is before mach will think the probe is triggered - and then it has to decelerate and stop.....
One might want to consider - how much tip travel does the probe have? 0.133 inches over travel could be hard on the probe -  depends on the probe design.

Same scenario with 200 debounce: 50ipm * (200*40usec) / 60 sec/min = 0.0067 inch over travel

Personally, I prefer to see a debounce of no more than a few hundred. but the real answer is whatever combination works that makes the machine run reliably.

Play with the numbers and decide what you are comfortable with.

Dave

298
Hi readers -
Ventuseu's issue is still under investigation.

Currently, I suspect a problem resulting from the use of a "pin multiplexing" break out board. These type of boards are not pure hardware; they depend on vendor supplied Mach plug-in. They allow one to put multiple signals on a single mach input pin and time division multiplex the pin. I'm hypothesizing that this causes an incorrect state of the probe input to be read when mach looks at the input signal - which results in the probe operation failing.

So, I'm wondering:
Is anyone else using a multiplexing BoB with MSM to do probing?
If so what brand and model BoB?

Dave

299
CVI MachStdMill (MSM) / Re: Homing and Limit Switch Probblems.
« on: August 06, 2010, 11:21:44 PM »
This is a bug. Thanks for spotting it.

The reason X acted backwards is that it was on pin 11. Pins 1, 11, 14 & 17 have hardware inversion on the lines.
The logic that drives the led display for the PP page was forgetting to invert the LED state to compensate for the hardware inversion in the PP. Thus the Leds for pins 1, 11, 14 and 17 were displaying "reversed".

You other switch signals were ok as they were on pins 12,13,14 which do not have PP hardware inversion.

I've fixed this for the next MSM release.

Dave

  I also have something strange going on with the limit switches.  I have a home switch at one end  and a limit at the other end of each axis.  Each switch is wired normally open and the two are in parallel.  X axis is connected to input 11, Y to 12, Z to 13, and A to 15.   The parallel port monitor page shows pin 11 to be low and the other 3 to be high as they should be.  In fact all are high and go low with switch activation  as is verified by looking at the LEDs on the breakout board.  Toggling the home or limit on the X axis makes the bit go high on the PP monitor screen.  Exactly backwards.  The other 3 display as they should.  All inputs are marked as neg active on the setup page and the homing/ref all works as it should. 
  So the question remains - why is input 11 shown backwards from the rest???
  Larry

300
CVI MachStdMill (MSM) / Re: Homing and Limit Switch Probblems.
« on: August 06, 2010, 09:23:52 PM »
Hi,
If Calum's idea is not the solution, keep reading.

Let’s determine if the problem really follows the screen set in use or the profile (XML) file in use.
The following is very similar to the "Divide and conquer" debug technique we used in another thread - so if you've been reading the other posts this will sound familiar.

You currently have two profiles, one for 1024 and one for MSM.
Let's give them some names just to make it easier to talk about them in this post.

Profile1024 is your "original" profile and the one where homing works with 1024.
I’d guess it's the profile that you have used before MSM can along to run the machine. We know it has the correct ports & Pin information and that homing works correctly for the combination of this profile and the 1024 screen set.

ProfileMSM is "Newer"" - I think you created it by using mach loader to make a copy of Profile1024 and then added the MSM option settings to the copy. For some reason the combination of this profile and MSM does not home correctly for you.

Here are some steps which hopefully, will let us determine if the problem lies with a screen set or a profile (XML file).

If at any point in the process, something goes badly awry, please stop; and let me know what happened.
Read thru the steps before starting to see if they make sense to you - I wrote them off the top of my head and I could have said something wrong n the course of writing them...

*** Note: In all of the "copy profile" steps below, DO NOT check "default Profile Values" in the Create profile dialog box. ***

First we try the 1024 profile with MSM to see what that tells us:
1)   Use mach loader to make a copy of Profile1024 – we‘ll call it Profile1024Base-w-MSM.
2)   Start mach using Profile1024Base-w-MSM.
3)   Use menus to view – load screen set and load up C:\Mach3\MachStdMill.set
4)   Close mach to get this change written into the profile
5)   Restart mach, again using Profile1024Base-w-MSM; mach should start and load up MSM.
6)   Click either the REfZ or Ref All Home button -

If the homing/reference issue is now gone, we now are pretty confident that whatever the problem is, it is in the ProfileMSM XML file.
(If the Homing problem still exists, I guess I want you to tell me that too….  :(     )

To double check this, let’s also do the opposite test:
7)   Use mach loader to make a copy of ProfileMSM – we ‘ll call it ProfileMSMBase-w-1024.
8]    Start mach using Profile1024Base-w-1024.
(the above line is 8] because 8-right-paren is 8)  ) -  :'(
9)   Use menus to view – load screen set and load up C:\Mach3\1024.set
10)   Close mach to get this change written into the profile
11)   Restart mach, again using ProfileMSMBase-w-1024 mach should start and load up 1024.
12)   Click either RefZ or Ref All Home button and let me know what it does.

If the homing/reference issue now happens with 1024, we have doubly confirmed that whatever the problem is, it is hiding inside the ProfileMSM XML file.

13)   Close mach
14)   Delete ProfileMSMBase-w-1024 – we know it is bad and so there is no reason to keep it around to cause trouble later.

If the above tracks with results so far, you have a working MSM profile (rather than spending lots of time looking for the mach setting that is different between the profiles).

(Don't fret about the fact that the new prpfile does not have the exact options ettings from teh MSM readme. I'm going to revise the readme to make it much simpler for the next release. Truth be told, MSM will operate with any combo of mach options settings.)

Time to clean up:
20)   Delete ProfileMSM – it’s known bad.
21)   Rename Profile1024Base-w-MSM to ProfileMSM

We’re done:
     Profile1024 is your profile for running 1024.
     ProfileMSM is your profile for running MSM.

Dave


Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 »