Hello Guest it is March 29, 2024, 11:32:53 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 - Analias

Pages: « 1 2 3 4 5 6 7 8 9 10 11 »
61
Mach4 General Discussion / Homing function - Is this unreasonable?
« on: July 28, 2014, 01:48:02 AM »
I'm trying to provide a generic homing procedure that would be run when an ISIG_MOTOR#_PLUS/MINUS signal gets sent while homing.  When I run it on my Sieg X3 mill and trigger a limit switch (all of mine are tied to pin 11 on the BOB) Mach 4 go into lala land - CPU usage jumps to 100% and Mach 4 hangs.  I have to kill the app and restart.

I wanted to make sure I'm not doing something unreasonable in my signal handling code:

Code: [Select]
-- In screen signal handling

local isHoming = false;

SigLib.AddSignalHandler(mc.ISIG_MOTOR_HOME_START, function (state)
    isHoming = (state == 1);
end)

-- Limit switches

SigLib.AddSignalHandler(mc.ISIG_MOTOR0_MINUS, function (state)
    if (isHoming) then
        MySM.MoveMotorOffLimitSwitch(MySM.MOTOR_X);
    end
end)

SigLib.AddSignalHandler(mc.ISIG_MOTOR0_PLUS, function (state)
    if (isHoming) then
        MySM.MoveMotorOffLimitSwitch(MySM.MOTOR_X);
    end
end)

SigLib.AddSignalHandler(mc.ISIG_MOTOR0_MINUS, function (state)
    if (isHoming) then
        MySM.MoveMotorOffLimitSwitch(MySM.MOTOR_X);
    end
end)

In my Lau module:

Code: [Select]
----
--  Test if specified motor is on limit switch (due to homing) and move
--  in appropriate direction to move off of limit switch if needed.
--
--  WARNING : At the moment I am assuming a one-to-one mapping between
--                   motors and axis (ie. motor 0 -> axis 0, motor 1 -> axis 1, ...)
--
--  @param motor (number)   motor selector, 0-6
--
function MyStdMill.MoveMotorOffLimitSwitch (motor)
    local inst = mc.mcGetInstance()
    local directionToMoveOffLimit, isOnLimitSwitch;

    if (DSC.GetFunc('ISAXENBL', motor)) then

        if (DSC.IsPlusLim (motor)) then
            directionToMoveOffLimit = MyStdMill.DIR_NEGATIVE;
            isOnLimitSwitch = DSC.IsPlusLim;
        elseif (DSC.IsMinusLim (motor)) then
            directionToMoveOffLimit = MyStdMill.DIR_POSITIVE;
            isOnLimitSwitch = DSC.IsMinusLim;
        else
            return;
        end

        local axis = { [0]="X", "Y", "Z", "A" };  -- Select axis for Gcode based on motor
        local gcode = string.format("G90 G01 %s%d F5", axis[motor], directionToMoveOffLimit);

        mc.mcCntlSetLastError(inst, string.format("Moving motor %d off axis %s, direction = %d",
                                                                  motor, axis[motor], directionToMoveOffLimit));

        while (isOnLimitSwitch (motor))
        do
            mc.mcCntlGcodeExecute (inst, gcode);
        end

    end
end

Essentially in MoveMotorOffLimitswitch(), I'm checking which limit switch was triggered for the specified motor and choosing which direction to go.  I set "directiontoMoveOffLimit" to a positive or negative one to use as my unit of movement and to choose the direction.  I set "isOnLimitSwitch" to the DSC function for continuing to test for which limit switch we are on to use later in the while loop.  In the while loop I send a "G90 G01 {axis}{direction} F5" to move off the limit switch.


-Freeman

62
Mach4 General Discussion / Re: Screen Set Ideas
« on: July 27, 2014, 08:41:03 PM »
Thought others might like to play and experiment with a wizzard.

Thanks Craig,

Very timely since I'm trying to find where the current fixture # (not coordinates) are stored.  I'm trying to display which of G54-59 is current in effect.


-Freeman

63
In my playground screen set, I have a touch off and probing screen.  In it I have a bitmap image of a simplified work piece and the probing operations that are possible off the work piece (surface, edge, corner probing, etc.).  I was hoping to be able to capture where I clicked on the image, but the bitmap component doesn't appear to support any feedback.  Am I barking up the wrong tree?

I guess I'm thinking of something similar to image maps in HTML.


-Freeman

64
Thanks Craig that's helping.

One idea I had, if it doesn't already exist, is a command line option to come up in GUI edit mode.  That would allow the startup process to be avoided and have the user to be in the right place to do something about fixing it.

UPDATE - Uhm guess what?  There is an option to come up in edit mode, -e :D


-Freeman

65
While testing my own code, I've ran into a problem where starting Mach 4 causes a hang in the middle of the "Loading screen elements...".  I'm sure I introduced the problem, but how do I find it?

Ideally I could interrupt the startup and look at the stack trace.  A watchdog timer would be nice on start up that would bailout and give me a stack trace.  Something to add to the list of features for Mach4?

Ideas would be appreciated.  I still need to find the cause of my hang.  :)


-Freeman

66
Hey Freeman, the DSC 3.0 module already does all that stuff, and much more, it would save you some time.......

Scott

Scott, have you seen my latest response to your DSC 3.0 thread? I still can't import the module. Have you been able to use it with build 1900 or later? I haven't tried with build 1915 yet. It still appears to be a compile version issue. Could you recompile under build 1915 and send me the mcc file?

I've been forced to duplicate much of what DSC 3.0 does :-(

-Freeman

Sent from my Xoom using Tapatalk

67
Uhmmm (grrrrrr.....) - A restart of Mach 4 fixed the problem.

Sorry, nothing to see here - please move along.  No pictures please.  No ma'am, it's just the village idiot...

-Freeman

68
I should also mention that the following test script runs and calls MySM.plcScreenSetName() just fine:

Code: [Select]
function GetMachDir ()
  local inst = mc.mcGetInstance();
  return mc.mcCntlGetMachDir (inst);
end

local machDir = GetMachDir();

package.path = "./?.lua;" ..
               machDir .. "/?.dll;" ..
               machDir .. "/Modules/?.mcc;" ..
               machDir .. "/Profiles/MyStdMill/Modules/?.mcc"

MySM = require "MyStdMill"
SigLib = require "SigLib"

function test ()
    local inst = mc.mcGetInstance()

    mc.mcCntlSetLastError(inst, "package.path = " .. package.path)
    mc.mcCntlSetLastError(inst, "MySM = " .. tostring(MySM))

    SigLib.AddSignalHandler(mc.OSIG_HOMED_X, function (state)
        mc.mcCntlSetLastError(inst, "state : " .. tostring(state))
    end)

    SigLib.DispatchSignal (mc.OSIG_HOMED_X, 1)

    MySM.plcScreenSetName(inst)
end

if (mc.mcInEditor() == 1) then
    test()
end

-Freeman

69
I'm having a an odd problem within my screen PLC script.   I don't know if it's a Lua issue or something about the PLC script.

I have two local modules that I have created, SigLib.mcc and MyStdMill.mcc.  Both I import using a require in the screen startup script.  I make SigLib calls in the screen startup and signal scripts, and it works flawlessly.  I only make MyStdMill calls in the screen PLC script.  Even though debugging shows the table containing the module is there (it has a non zero value), all my function calls cause an error since they are nil value. 

I thought that anything imported in the screen startup script should be seen in the PLC script.  Is this not the case?

-Freeman

Code: [Select]
-- Startup script

function GetMachDir ()
  local inst = mc.mcGetInstance();
  return mc.mcCntlGetMachDir (inst);
end

local machDir = GetMachDir();

package.path = "./?.lua;" ..
               machDir .. "/?.dll;" ..
               machDir .. "/Modules/?.mcc;" ..
               machDir .. "/Profiles/MyStdMill/Modules/?.mcc"

SigLib = require "SigLib"
MySM = require "MyStdMill"

Code: [Select]
-- PLC script

MySM.plcScreenSetName(inst)

MySM.plcAxisScaling(inst, 'droMySMScaleX', 'iRegs0/xScale')
MySM.plcAxisScaling(inst, 'droMySMScaleY', 'iRegs0/yScale')
MySM.plcAxisScaling(inst, 'droMySMScaleZ', 'iRegs0/zScale')
MySM.plcAxisScaling(inst, 'droMySMScaleA', 'iRegs0/aScale')

Code: [Select]
-- MystdMill.mcc Module

local MyStdMill = {}

function MyStdMill.plcScreenSetName (inst)
  -- code abbreviated
end

function MyStdMill.plcAxisScaling(inst, dro, reg)
  -- code abbreviated
end

return MyStdMill

70
Mach4 General Discussion / Re: Mach4 Printer Port Discussions
« on: July 23, 2014, 12:37:45 AM »
Mach 4 build 1900
Darwin 1.10? (says 1.09/1.08 after removing and re-installing)

Completely reconfigured and everything appears to be working well.  I'll have to try configuring my spindle next and see if it behaves.

Art, one day I hope you can release the code for Darwin - after you have made you billions.  I really want to know the black magic you used to do this.  I've been a computer geek and developer for over 25 years and you PP driver still amazes me.  I could do it under Unix/Linux (I've written device drivers and kernel modules), but under Windows - never.


-Freeman

Pages: « 1 2 3 4 5 6 7 8 9 10 11 »