Hello Guest it is April 29, 2024, 06:40:47 AM

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 - Fledermaus

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 »
121
Mach4 General Discussion / Re: Jog steps
« on: March 10, 2018, 11:33:40 AM »
Sadly the documentation tends to lag behind development - a consequence of the low price of Mach4.

Sorry I cannot remember where I found the above API call. I assume it must have been in a forum post or in the change notes, but I've just done a quick search and nothing showed up.

Allan

122
Mach4 General Discussion / Re: Jog steps
« on: March 10, 2018, 09:39:44 AM »
Look at:

  C:\Mach4Hobby\Docs\Mach4CoreAPI.chm

You may need to install a viewer such as xchm to read this file.

I'm not sure why DefUnits would change, but you could assume 21 to force metric for jogging:

  rc = mc.mcJogSetUnitsMode(inst, axis, 21)

Allan

123
Mach4 General Discussion / Re: Jog steps
« on: March 10, 2018, 06:31:34 AM »
I think this issue results from the configuration. You could try a later version to see if it has been fixed. or you might try issuing the following after configuration and prior to jogging:

    local defUnits = mc.mcCntlGetUnitsDefault(inst)
    rc = mc.mcJogSetUnitsMode(inst, axis, defUnits)


Allan

124
Try this (I haven't tested it):

    local out1handle = mc.mcSignalGetHandle(inst, mc.OSIG_OUTPUT1)
    mc.mcSignalSetState(out1handle , state)

In C, the state is true/false, but in LUA it is 0/1.

Allan
 

125
Mach4 General Discussion / Re: Mach4 and CSMI0/IP-A
« on: February 28, 2018, 07:57:09 AM »
As far as I know, unfortunately there will be no further development of the v2.910 plugin. From the CSMIO Quick Start manual, it appears that threading might not be supported with Mach4, but if no one here is using the CSMIO/IP-A on a lathe it might be worth asking CS Labs what support is offered.

Using the mill, v2.910 was very reliable.

Allan

126
Mach4 General Discussion / Re: Mach4 and CSMI0/IP-A
« on: February 28, 2018, 05:56:15 AM »
I use a CSMIO/IP-A on a mill, and the basics work very well. One thing about the CS Labs kit is that you will have no problems with electrical noise: the 24V levels and isolation are very effective.

Do you have the FP4 version of the controller which uses the latest v3.08 plugin or the older version which uses the v2.910 plugin?

Sorry I have no idea how lathe support stands for this unit, but my advice is just try it; you can always revert to Mach3 until the features you need have been implimented. Getting used to LUA will take some time, but it is well worth the effort as Mach4 offers great flexibility and responsiveness.

Allan

127
In case anyone else is struggling to get Steve's code working, as I was, here is the content of the file screenipc.mcs that I placed in my macros directory:

Code: [Select]
inst = mc.mcGetInstance()
local profile = mc.mcProfileGetName(inst)
local path = mc.mcCntlGetMachDir(inst)
package.path = path .. "\\Modules\\?.lua;" .. path .. "\\Profiles\\" ..  profile .. "\\Modules\\?.lua;"
package.cpath = package.cpath .. ";./Modules/?.dll;"


scr = require("screenipc")
scr.scIpcInit('127.0.0.1')


Many thanks for this Steve: it works a treat. I too was previously setting registers in a macro and then polling them in the PLC script only to update screen elements, so this is a much better way to achieve the desired result.

Allan

128
You might also like to try the following: API call

    number scr.ButtonDown(string ctrlName) -- Simulate a button down event.

Substitute the actual soft limits button name for ctrlName in the above. I haven't tried this, so there could be side effects.

Allan

129

Yes, I remembered your post re limited range for mc.SignalWait(). Thanks for saving me from that pitfall.

MERROR_NOT_NOW does seem to crop up occasionally. It is frustrating because one is usually mystified as to its cause and yet it provides no clue as to the solution.

Allan

130
Mach4 General Discussion / Re: Coroutines, Button Scripts, Modules, Probing
« on: February 04, 2018, 03:58:20 PM »
Coroutines have been a bit of a mystery to me: I am much happier with the concept of independent threads and semaphores. So thank you for posting and whetting my appetite to give them a try.

I too have extensively re-written the mcProbing module. Amonst other things, all Gcode is funnelled through a single function, the idea being that it would be easy to incorporate the necessary coroutine.yield() call if I decided to go down that path. As I have found that the GUI does not lock up even though I exclusively  use mcCntlGcodeExecuteWait  I had not taken that option.

Seeing your post left me unable to resist giving coroutines a try in a tool length measuring function that I was working on. This is initiated by a call from a button script. I found that with or without the coroutine approach, the function worked well, moving the tool over a sensor, probing, and returning the tool to its starting position without any obvious lock up or drag on the GUI.

I then ran a small program with an M6 macro that waited on a signal for manual tool insertion. During this hold, Mach4 remained in a File Run  state. I tried running the measurement function, again via a screen button, during this M6 hold. I modified the coroutine.resume function to test for the File Run  state in addition to Idle.  I found that the original routine ran perfectly during the M6 hold, with no GUI lock ups. To my complete surprise, the coroutine version of the routine locked up the DROs  which only caught up when the routine had completed.

This has left me wondering whether coroutines are the panacea that I had once imagined. I have removed them from my code, at least for now, as it seems to work better without. I welcome any ideas as to what might have caused the poor performance with coroutines when in the macro hold, as I am currently mystified by it.

Allan

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 »