Messages

131

Mach4 General Discussion / Re: MERROR_NOT_NOW from GcodeExecuteWait() API Call

« on: February 04, 2018, 03:08:35 PM »

Well I found my error that was frustrating the tool height measurement.  I had requested a probe move that would have taken Z below the minimum soft limit. Once I fixed that, the routine worked repeatedly and well, whether called from a screen button in the Idle state, from a screen button during an M6 File Run state, or from within the M6 macro itself. The macro was held using  mcSignalWait.

I am beginning to think that MERROR_NOT_NOW is simply a catch-all message, meaning that as a diagnostic aid it is next to useless. I say this because the same error was produced when attempting to run the button script when Mach4 was disabled.

Allan

132

Mach4 General Discussion / Re: Manual touch plate probing after manual tool change

« on: February 04, 2018, 02:48:59 PM »

Sorry, I forgot the parameters in the above:

mc.mcCntlCycleStop(inst)
mc.mcCntlEnable(inst, true)

Allan

133

Mach4 General Discussion / Re: Manual touch plate probing after manual tool change

« on: February 04, 2018, 07:13:29 AM »

I found that in order to be able to both jog and run code I had to follow cycle stotp by enable as follows;

mc.mcCntlCycleStop()
mc.mcCntlEnable()

Without this I would get  MERROR_NOT_NOW even though the state was Idle.. Doesn't make much sense to me.

Allan

134

Mach4 General Discussion / Re: MERROR_NOT_NOW from GcodeExecuteWait() API Call

« on: February 04, 2018, 06:07:38 AM »

Craig

I too have experienced this sort of behaviour. It begs the question when does Idle mean Idle? One answer, as you have found, is when it is followed by Enable.

I have a tool height measuring function, based on the mcProbing module (though I have totally restructured/rewritten the first 2000 lines or so) that lifts the tool, sends it over the sensor, does a 2 strike G31.1 probe down to the sensor , then lifts and returns the tool to its starting position. If it succeeds, it sets the Fixture offset or Tool table entry (user has the option) for length compensation.

On my office PC, it runs perfectly in the SIM, though of course the probe strike does not occur.  It runs from a screen button push either from an Idle state or when code has been halted in the File Run state by an M6 macro. (The macro uses SignalWait().)) I am not using coroutines as the GUI does not appear to freeze. With a coroutine approach, I found that the code ran fine normally, but froze the screen when run during the M6 hold.

On my CSMIO system, the same code lifts the tool and moves it over the sensor, but then fails with that infuriating errorMERROR_NOT_NOW. As yet, I haven't drilled down further to see what's happening., but it's on my list for attention.  

Allan

135

Newfangled Mill Wizard / Re: Licence policy different from Mach4

« on: February 03, 2018, 11:29:26 AM »

I understand that you need a separate licence for each machine running the Mill Wizart. Like you, I would prefer a bit more flexibility, as per Mach3/4. Many of us use a separate PC just for design, and would like to have the wizard on that as well as the CNC machine..

Allan

136

Mach4 General Discussion / Re: Mach4 Button OFFLINE

« on: February 03, 2018, 11:13:31 AM »

Craig

OK. I tested the macros on my CSMIO system.

 I started Mach4, left it disabled, and opened m201 in the debugger. Running the code, the M0 Enable LED turned on, and I could tell from the locking of the X axis motor that the CSMIO output had also been activated. So far so good. Next I ran m200 in the debugger. the M0 Enable LED turned off as expected, but contrary to my expectations the CSMIO output remained active, i.e. the X axis motor was still energised.

Pressing Enable/Disable caused the motor to lock and unlock, as expected.  I then ran the m201 macro again in the debugger,  This time the M0 Enable LED came on, but the CSMIO output did not, i.e. the motor remained unenergised. Enabling Mach4 and running the m200 macro in the debugger similarly produced no response from the CSMIO, i.e. in this scenario the M0 Enable LED turned off but the motor remained energised.

Finally I enabled Mach4 and ran the 2 macros from the MDI window. Neither had any effect, either on the LED or on the motor itself.

Though the results do not entirely echo those using the simulator, the overall conclusion remains that the Enable outputs cannot be programmatically changed using  API calls from user scripts. Your current approach ingvolving a second output and external logic would therefore seem to be the way ahead if this type of functionality is needed.

Note that my system does not exactly  echo that of the op. I have the CSMIO/IP-A with the latest v3.08 (beta) plugin. I couldn't do what the op hopes to achieve,  even if I wanted to, as the IP-A is closed loop and so would ssurely generate a PID error as soon as the motor position failed to match that expected by Mach.

Allan

137

Mach4 General Discussion / Re: Mach4 Button OFFLINE

« on: February 02, 2018, 04:14:29 PM »

Craig

I have had another look at this on my office PC using SIM. The plot thickens:

If I run the macros from the debugger, the M0 Enable LED does indeed respond to the macros, as you have observed. If, on the other hand, I execute the macros from the MDI window, there is no response. Make of that what you will.

I will try to remember to go out and run this on the CSMIO over the weekend, just for the sake of completeness.

I think you are incorrect in asserting that output pins cannot be arbitrarily assigned by the CSMIO. I have never seen evidence of this.

Allan

138

Mach4 General Discussion / Re: Mach4 Button OFFLINE

« on: February 02, 2018, 09:49:52 AM »

Craig

Sorry for the delay in responding.

I created a pair of simple macros to set and reset  OSIG_ENABLE0 and ran them manually from the MDI window of the Diagnostics tab. They had no effect on the Enable0 LED on that screen. I then changed the macros to control   OSIG_OUTPUT0 and this time the related LED reacted accordingly.

It does appear that Mach4 keeps a tight control over the motor enable  signals which are fundamental to machine control. I was using the simulator on my office PC, so it appears that the op's CSMIO is performing in the expected manner and it is your system that is behaving differently.

Personally, I just test my Gcode programs using the simulator in the office, and have never found a discrepancy between this and my CSMIO system.

Allan

139

Mach4 General Discussion / Re: Mach4 Button OFFLINE

« on: February 01, 2018, 05:33:43 AM »

Craig

Of course CSMIO recognises OSIG_ENABLE0 - I use it to enable Motor 0. I think the issue you were having may be a conflict with the core, as the signal was changing in response to Enable/Disable, as it normally does.

Though Mach's LED reacted in response to OSIG_ENABLE0, it would have been interesting to know if the LED on the CSMIO itself also reacted, proving that the command was reaching the controller.

Though the CSMIO is not perfect, it performs very solidly on the basic functions such as I/O.
Allan

140

Mach4 General Discussion / Re: Mach4 Button OFFLINE

« on: January 31, 2018, 07:17:00 AM »

I use a CSMIO/IP-A and experience no problem in attaching any listed signal to a chosen I/O pin. CS Labs do not appear to impose any undue restrictions on this.

 OSIG_ENABLEx are normally used to enable drives and there is no problem assigning output pins via Mach4's Output Signals configuration.

OSIG_ENABLE0 is normally generated by the core, so it is debatable whether users should be directly programming it.

Allan