Hello Guest it is April 28, 2024, 10:11:43 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 - mcardoso

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 »
201
Warp9TD confirmed the spindle issue I am seeing is some sort of bug. They are working towards a solution.

202
Related to #3 on the original post, I have continued to have some issues with the spindle whenever it is accelerating, changing speeds, or decelerating to a stop. Not sure if it is a wiring, Mach, or ethernet smoothstepper issue, but the servo seems to receive delayed or missing steps which cause significant clunking in the drivetrain and occasionally a drive fault. I have a workaround to limit the servo acceleration at the drive level but this isn't the best fix.

I have a support ticket in with Warp9TD (whose support is A+) so it will be interesting to see where it goes.

Few trends showing what should be a smooth ramp in commanded speed of the spindle motor, but has a dip back to 0rpm which causes aggressive jerking of the spindle:

Note that the graphs are inverted to -5000 rpm due to the drive polarity, but it doesn't make a difference.


203
If the above post is not clear, let me know and I will try to explain better.

204
Well ok... I went off on a spiritual soul searching (learning coroutines) journey and I am back... With a few questions.

Long term goal: Write and read serial data to Ultra 3000 servo drives over RS485. Use data for Mach 4 functions like spindle load monitoring, absolute homing, etc.

I have gotten serial communications working and when I get this whole thing perfect I will make a write-up for anyone who wants to use ASCII serial. I have gotten coroutines working, but I am a little confused on how to handle the code structure.

Here is what I want (pseudo code)

Code: [Select]
------------------------
--PLC Script, 50ms --
------------------------
myTorque = servoGetTorque(address)
>>Copy torque data to register to use for on screen bar graph


------------------------
--Screen Load Script --
------------------------
wxTimer function()
    >>resume coroutine
end

appendChecksum()
    >>appends a checksum to the serial string for transmission
end

coroutineFunction()
    >>append checksum to transmission string
    >>Transmit String
    >>Start Timer, roughly 5ms
    >>Yield Coroutine
    >>Coroutine resumes here
    >>Read serial buffer
    >>Check data checkum
    >>Return data
end

function servoGetTorque(address)
    >>Create transmission string
    local state = coroutine.status (DriveComm)
    if (state == "dead") then
        >>create coroutine, pass in transmission string
    end
    Return torque data when entire coroutine is finished
end

The one problem I haven't yet figured out is that the coroutine returns when it is suspended. So if I were to use the above function, it would return after the transmission. The second half of the code (reading the serial buffer) returns to the background timer resume coroutine call. This makes getting the data myTorque impossible, because when servoGetTorque() returns, we haven't yet read the serial port.

I really want to abstract all the communications to calls like myTorque = servoGetTorque(address), so can anyone suggest how to handle the coroutine returning to a different location.

205
Mach4 General Discussion / Re: Windows 10?
« on: March 21, 2019, 09:17:48 AM »
Running an ESS on a low performance (1.9GHz processor, 4 GB ram) industrial PC running Win10 OEM (stripped down to nothing). Runs great. No issues to date.

206
Mach4 General Discussion / Re: Proper way to use work / tool offsets
« on: March 19, 2019, 09:05:50 AM »
Craig and Cbyrdtopper,

Thanks much for the info! I watched all those videos last night and they really helped! I think at this point I just need some spindle time with the fixture table open to see what is going on. Does Mach 4 support the extended work offsets beyond G59?

207
Mach4 General Discussion / Re: Proper way to use work / tool offsets
« on: March 18, 2019, 03:42:00 PM »
Craig, this was just what I was looking for. Thank you.  I will have to play around with the offsets and try resuming a program after powering down.

208
Craig, Awesome Reply.


For anyone curious about where I am at on some of the original questions:

1) The signal script contains a short chuck of code that says "if the button is pressed, extend the drawbar, if the button is released, retract the cylinder and start a 500ms timer to turn off the solenoid" Apparently this gets scanned when exiting the Configure/Control menu and since the button is off, the retract solenoid fires. Doesn't seem to happen every time. I will figure out a way to interlock this so it doesn't happen, but it doesn't cause harm other than a startling pop when the solenoid fires.

2) This was a big deal to me when it was happening, but I have been unsuccessful in recreating the problem since I posted this. I'm chalking it up to a glitch in Mach/ESS that hasn't happened again. I am using the home to marker/Index feature of the ESS and love the functionality. It repeats to the .0001 on the DRO's, where the limit switches themselves are not nearly that accurate (nor do they need to be). I'm crossing my fingers I no longer have homing/limit issues.

3) This is still a big issue for me. Any M03/M04/M05 call in the code causes a clunk or two when accelerating, changing speeds, or decelerating. This behavior is seen using MDI or GCode, but it doesn't seem to happen with the M03 button on screen (although I could be wrong on that). This used to fault my drives on an overvoltage which tells me the pulse train was delayed ever slightly and the drives responded by attempting to instantaneously decelerate.

The Allen Bradley Ultra 3000's I am using have a setting called Slew Limit which sets the maximum acceleration /deceleration that the drive will allow even when the Step/Dir input goes faster, however the correlation of position between Mach and the drive is lost when this limit takes effect, so I would prefer not to use it. I currently have it set at twice the Mach 4 programmed spindle acceleration and it has gotten rid of the overvoltage issue (however I can still hear the clunks in the spindle drivetrain). This issue is not seen/heard on any of the coordinate axes, only the spindle.

209
Mach4 General Discussion / Proper way to use work / tool offsets
« on: March 18, 2019, 10:56:55 AM »
Hi all, this is more of a "teach me CNC" than a Mach 4 specific issue, but I was hoping to get your thoughts.

For the first time since I started this hobby, I have a machine with home/limit sensors. I used to just open Mach 3, zero the machine coordinate system at the work zero and cut away (all work offsets being zero). If the power went out and I machined off the corner I used to zero the part, then the part was scrap.

Now I turn on the machine, home to inductive proximity sensors, then home to the servo encoder marker pulse. This seems to be very repeatable - as it should be. My question is about how to properly use work offsets. After this homing sequence, I believe the machine starts in G53 and is located at 0,0,0. From there, I believe you can write gcode relative to a work zero defined in G54-G59. What it seems like I need to do is go into the MDI, enter G54, then edge find my part zero. When I zero this, does mach automatically and permanently save the work offset? Is there something I need to do in order to get it to be saved?

Now for tool offsets. I preset my tool lengths off the machine relative to the nose of the spindle. My code typically has a call like:
M06 T5
G43 H5
This loads the tool and height offset info for tool 5. Sometimes it seems like the first line runs and throws some weird number into the Z axis DRO, then when the second line runs, the correct tool position is reloaded into the DRO. I ran into an issue where this weird number triggered an error of being outside of soft limits even though the tool was perfectly well inside the limits.

What is the proper procedure to turn on the machine, home, locate the work zero, save the work offset, and handle tool length offsets?

Thanks!

210
Chaoticone,

Thanks for the thoughts! I would prefer to keep the resetting of the coroutine out of the PLC script since I would like to reserve that for operations which MUST be on a periodic task. This would also avoid delays between when the coroutine becomes dead and when the PLC script runs. Two questions:

1) Can the first chunk of code you posted previously be placed in the ScreenLoad script? Will it detect the change in coroutine state there?

2) Can the function called by the coroutine be defined separate from the creation of the coroutine?  For example, is this allowed?

Code: [Select]
function DoThis(x)
--stuff here
end

placeholder = coroutine.create(Do this(x))



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 »