Messages

3131

Mach4 General Discussion / Re: enable output

« on: February 04, 2019, 01:16:14 AM »

Hi,
that's a pretty ambitious script for a Mach4 newbie. Are you convinced you require such a feature/machine behavior?

What's more important.....making chips or having flashing lights?

Craig

3132

Mach4 General Discussion / Re: How do I wait for spindle at zero in my script?

« on: February 04, 2019, 01:06:15 AM »

Hi,
I'm using 3804 and the numeric range of the valid input signal ID's is complete for ALL defined input signals.

mcSignalWait() is one of the few APIs for which I test EVERY MERROR.....I've been caught too many times with this API
doing something weird because of some condition that I didn't think about.

Craig

3133

Mach4 General Discussion / Re: How do I wait for spindle at zero in my script?

« on: February 03, 2019, 12:08:17 PM »

Hi,
there was a time when I had a similar problem with the mcSignalWait() API, and the MERROR_INVALID_ARG.

It turns out that at that time the numeric range of the signal IDs was only up to 64 whereas ISIG_SPINDLE_AT_SPEED
is 120 or so. Try using ISIG_INPUT20 say. I thought the fault had been corrected but maybe you have an early build.

Craig

3134

Mach4 General Discussion / Re: Home/reference OB axis

« on: February 03, 2019, 07:43:22 AM »

Hi,

So basically, ESS can't handle homing of OB motors if I understood you correctly?

No, that is incorrect. The ESS has real-time facilities for up to six motors. Your coordinated axes XYZA use four,
the spindle is an OB axis as is the carousel motor for six total. Thus the ESS has hardware facilities for homing
of up to six axes.

Note that the spindle is a special case of an OB axis. It does not get homed per se. If you wish it to be homed
then it is appropriate to call it a C axis.

You cannot set the machine coordinates of an axis programmatically.

[url][https://www.machsupport.com/forum/index.php?topic=39309.0/url]

I cant see that your code is going to achieve much.

Consider the first API:
rc = mc.mcAxisSetMachinePos(
      number mInst,
      number axis,
      number val)
and in particular the additional notes:
val The desired axis position to apply a fixture offset.

And the C syntax example:
// Set axis 0 fisxture offset.
int mInst = 0;
mcAxisSetMachinePos(mInst, 0, 0.0 /* set part zero */);

So the API DOES NOT set the machine coordinate, it sets the fixture offset.

The next API you have used is in effect a duplicate:
rc = mc.mcAxisSetPos(
   number mInst,
   number axisId,
   number val);

Description:
Set the Position of an axis by changing the fixture offset

But see the additional notes:
Notes:
Set the position of the axis by changing the current Fixture offset. This is not valid for out of band axes.

But note the description......changing the fixture offset and in the attached notes ....not valid for out of band axes.

And the last AI you have used:
rc = mc.mcAxisGetHomeInPlace(
      number mInst,
      number axisId,
      number homeInPlace)

Description:
Set the axis' Home In Place flag.

Notes:
The core provides a container for the axis home in place flag only. It currently does nothing with it. However, a motion plugin may retrieve the stored flag and implement a means to home the axis and set machine coordinate 0 at its current location.

So you can set the flag programmatically but you cannot cause the machine coordinates to be rest, that is up to
the motion plugin, in your case the ESS.

You have used APIs without carefully reading/considering what they can and cannot do.

Craig

3135

Mach4 General Discussion / Re: How do I wait for spindle at zero in my script?

« on: February 02, 2019, 06:48:12 PM »

Hi,
couple of things I have spotted.

the  API is;

LUA Syntax:
rc = mc.mcSignalWait(
      number mInst,
      number sigId,
      number waitMode,
      number timeoutSecs);

But note in the descrition:

sigId A valid signal ID. (NOT a signal handle)

A signal ID not a signal handle. You are using a signal handle and that is incorrect.

The potential error states are:

MERROR_NOERROR No Error.
MERROR_INVALID_INSTANCE The mInst parameter was out of range.
MERROR_INVALID_ARG sigId or wiatMode is out of range or timeoutSecs is negative.
MERROR_NOT_ENABLED The control is not enabled.
MERROR_TIMED_OUT The timeout period was reached without a change of state.

         0  =   MERROR_NOERROR   
   -1  =   MERROR_INVALID_INSTANCE
         -2 =    MERROR_INVALID_ARG
        -31  =   MERROR_NOT_ENABLED
        -40  =   MERROR_TIMED_OUT

I will attach a file that has the list of numeric error state equivalents.
Thus given that you are using a signal handle instead of a signal ID in line 4 is why you are getting MERROR_INVALID_ARG.

As for line 3 you are using a signal ID when you should be using a signal handle.

 --local ret2 = mc.mcSignalGetState(mc.ISIG_SPINDLE_AT_ZERO)SpindleAtZero)       SpindleAtZero is a handle.....

Craig

3136

General Mach Discussion / Re: Y-axis motor not running in sync

« on: February 02, 2019, 06:26:42 PM »

Hi,

- start the calibrate process in the settings page
- choose the axis Y-axis in this case
- tell it how far to move (i've then already checked where the torch is in relation to the edge of the table)
- measure how far it actually moved and give that measured value back to mach
- mach then gives me a updated steps per value and asks me if i want to use that value.

is this correct?

Yes, that is the process. You will have to make a guess as to the correct starting point. You need to measure it as best
as possible. If you are going to rely solely on the Mach routine to calibrate the axis for you are going to have trouble.

Craig

3137

Mach4 Plugins / Re: XHC WB04 plugin

« on: February 02, 2019, 05:44:39 PM »

Hi,
to be honest given XHC's apparent disregard for its customers why are you bothering?.

At this stage I would guess you know more about their device than they do and clearly care more about whether it
works than they do.

Why don't you make your own device and cut them out of the loop?

Craig

3138

General Mach Discussion / Re: Y-axis motor not running in sync

« on: February 02, 2019, 04:42:37 PM »

Hi,
Ok. Microstepping does not really improve the resoltuion of a stepper, as much as we might like to think it does.
The real value of microstepping is smooth motion.

A stepper at full step mode is highly inclined to vibrate, a so called mid-band resonance. A stepper in half step
mode is better and better again in 1/4 step mode. At about 1/8 step mode though you have gotten about as much
advantage as you are going to get and so microstepping in 1/16, 1/32, 1/64 step modes is just not worth it. You have
to signal the steppers that much faster to maintain axis velocity that you WILL have to increase the kernel speed
to the point of unreliability.

Given that you have fitted a gearbox that will make your stepper very much LESS subject to mid-band resonance
and you could robably recuce microstepping to 1/8 but 1/4 or 1/2 or maybe even fullstep would be OK.
May I suggest your existing 1600 pulse per rev (1/8 th micosteping) is adequate.

1600 pulses will rotate the stepper one turn but the gearbox requires five turns at the input to achieve one turn at
the output, so 5 x 1600 = 8000 pulses per revolution of the gearbox output shaft.

If you rotate the pinion one turn, how far does the axis travel?

If I guessed 75mm then the 'steps per unit' for that axis (with 1/8th microsteping and 5:1 gearbox) would be
8000 /75 =106.66 pulses per mm.

If you can accurately measure the distance the axis moves for exactly one rotation of the pinion you can calculate
the required 'steps per unit' value. If you can't measure it accurately then you will have to use the axis calibration feature
of Mach which is 'make a guess' try it and measure how far the axis went and adjust your guess to suit. Keep repeating
until its accurate. Thus making your initial guess as good as you can will help.

Craig

3139

General Mach Discussion / Re: Y-axis motor not running in sync

« on: February 02, 2019, 03:57:56 PM »

Hi,
the Mach3 kernel speed refers to the interrupt driven timer that Mach uses as its source of timing 'ticks' to generate
the motor pulse streams. Mach3 has a native kernel seed of 25 kHz.

You will have observed the 'jitter' which is reported by the DriverTest.exe program. Commonly the jitter or timing variance
will be 4 us. Remember that at 25kHz the period is 40 us. So the jitter is about 10% of the period.

You can as you have done increased the kernel speed but now the jitter (4 us) is about 40% or the period (10us)!
Quite frankly I'm surprised that you can get the parallel port to run at all! I would put it back to 25kHz. Note that you need
to restart Mach if you change the kernel speed. Once you have worked out the new (accurate) 'steps per unit' then you might
find it necessary to increase the kernel speed, but I've never heard of anyone getting good results at 100kHz.

The recommendation is that "Run Machs kernel speed at the lowest possible rate for the most stable results".

I think you have your settings all screwed up. If you had a 'steps per unit' value of nnn prior to the fitment
of the gearboxes then the new 'steps per unit' value should be 5 X nnn. It suggests to me that you have changed the
microstepping of your drivers as well.

What is the pitch of the ballscrews?
Are they direct coupled to the output of the gearbox?
Is the stepper direct coupled to the input of the gearbox?
What microstepping regime have you set your drivers to?

Craig

3140

Mach4 General Discussion / Re: Home/reference OB axis

« on: February 02, 2019, 02:04:49 PM »

Hi,
the ESS can handle six motors only.

Mach4 has Home inputs for 32 motors and allows for homing of u to six OB axes.
It's the ESS that can't do the business. Homing is a realtime operation, that is to say that the hardware
controller must handle homing as only the hardware is fast enough.

You can do it in software but you will have to home slowly. You want the fastest possible control loop.
I am thinking that the PLC script might offer the most direct and understandable route.

Craig