Messages

3181

Mach4 General Discussion / Re: Un-Supported wxNumberEntryDialog

« on: January 26, 2019, 02:03:07 PM »

Hi guys,
have taken your advice and reinstalled wxFormBuilder and been experimenting with it.

I have for experimentation purposes made a grid of data values within a frame. The Lua code all looks pretty straight
forward. It includes a Create function, I have excerpted it below.

Code: [Select]

-- Grid
UI.m_grid1:CreateGrid( 8, 1 )
UI.m_grid1:EnableEditing( True )
UI.m_grid1:EnableGridLines( True )
UI.m_grid1:EnableDragGridSize( False )
UI.m_grid1:SetMargins( 0, 0 )
I have copied and pasted the code into a macro but when I run the macro the expected data input frame doesn't show up.
I suspect (hope) its something basic that I'm overlooking.

I have been trying to assign a value to a local variable by using the GetCellValue function. One potential problem I see
is that when I use Zero Brane to write the line of code GetCellValue is not supported as an auto-complete item.
Is indeed GetCellValue supported by wxLua?

Craig

Code: [Select]

local jewelWidth=UI.m_grid1:GetCellValue(1,1)

3182

Mach4 General Discussion / Re: Motor Tuning in Mach 4, Very Stuck

« on: January 26, 2019, 01:09:08 PM »

Hi,
Chad has outlined the process spot on.

I'm running Nema 34 hybrid motors like the ledshine branded ones in 8.5nm and 12nm with SFU1605 leadscrews

Those are extremely powerful steppers. Often large steppers that have a great deal of torque do not have very high top
speeds before they start missing steps. You might be advised to treat the maximum speed as when the motors are doing 500 rpm.


If the steppers are direct coupled to the ballscrews then 500 rpm results in a linear speed of 2500 mm/min.

With steppers such as yours with high torque you can probably accommodate high or even very high acceleration. Chad has suggested
10% of your velocity, a good place to start, but I suspect, especially if you don't try to make them spin too fast, ie keep
the max velocity low then your acceleration could be much MUCH higher.

Often cycle times are improved as much if not more by high acceleration than axis speed. Certainly the higher the acceleration
your machine is capable of the more accurate parts will be when running in CV mode. The long and short of it is you need
to find the maximum safe and reliable acceleration your machine and motors can handle. Its more important than maximum
axis speed.

Can you tell us about the drivers and the settings you can make with them? Perhaps post the manual. If they are genuine closed
loop hybrid then there are a number of settings that will affect resolution and therefore your 'steps per unit'. Until you have the
'steps per unit' absolutely nailed down then any other motor tuning is a waste of time.

Craig

3183

Share Your GCode / Re: Wait for signal

« on: January 25, 2019, 04:04:48 PM »

Hi,
I am by no means an expert, scarely much more than a beginner.

I never bothered with the book, I just have the link open and delve into it at need.

Craig

3184

Share Your GCode / Re: Wait for signal

« on: January 25, 2019, 03:04:12 PM »

Hi,
OK that's easy enough. What you need to do is insert a 'wait on signal' macro immediately after each
move that requires it.

That can be done as a macro. So open the script editor and open a new document but save it in your macros folder
of your current profile m199.mcs
This is the code:

Code: [Select]

function m199()
local inst=mc.mcGetInstance()
local rc=mc.mcSignalWait(inst,mc.ISIG_INPUT4,mc.WAIT_MODE_HIGH,10)
if (rc==mc.MERROR_TIMED_OUT) then
mc.mcCntlSetLastError(inst,'Timed Out')
return
end


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

I have used this API (API.chm):
LUA Syntax:
rc = mc.mcSignalWait(
      number mInst,
      number sigId,
      number waitMode,
      number timeoutSecs);

Description:
Wait on a signal to change state.
Parameters: Parameter Description
mInst The controller instance.
sigId A valid signal ID. (NOT a signal handle)
waitMode An integer specifying whether to wait on the signal to go high (WAIT_MODE_HIGH) or low (WAIT_MODE_LOW).
timeoutSecs A double specifying a timeout period.


So in the code I have posted there is a 10 second TimedOut period while it waits for ISIG_INPUT4 to go high.

Craig

3185

Share Your GCode / Re: Wait for signal

« on: January 25, 2019, 02:07:24 PM »

Hi,
OK that makes sense.

How do you generate the Gcode for your pick-and-place machine?
What I am thinking is that after each move which requires a potential wait state that you would code a macro,
something like m199().

g0 x 123.456 y234.567                             --move to position A and be prepared to wait
m199()                                                    --macro that includes the wait code and when the signal is good then returns the machine
g0 x 567.890 y456.789                             --new move to position A and repeat
m199()

For every move which requires this 'wait on signal' behavior then you would have to add an extra line m199().
If you had many hundreds of moves that would be very tedious. Depending on how you generate the Gcode
you may be able to insert it automatically.

can you post a small excerpt of your code?

Craig

3186

G-Code, CAD, and CAM discussions / Re: G-Code bad character used

« on: January 25, 2019, 01:53:35 PM »

Hi,
or use pcb-gcode, a freely downloadable utility that attaches to Eagle and generates Gcode direct from your .brd file,
no sending files anywhere.....the gcode is generated within 10 seconds or so and is (or can be) Mach3/Mach4 ready.

It generates, at your option, Top Etch, Top Drill, Top Mill, Bottom Etch, Bottom Drill, and Bottom Mill. You can set etch, drill
and mill depths at will.

Craig

3187

Share Your GCode / Re: Wait for signal

« on: January 25, 2019, 01:38:58 PM »

Hi,
what I'm trying to work out is whether you need to insert a macro at each instance in your Gcode file where you wish this
behavior to occur or whether you need the machine to behave in this way whenever Gcode is running?

Craig

3188

Share Your GCode / Re: Wait for signal

« on: January 25, 2019, 01:35:53 PM »

Hi,
so you want this 'wait on signal' to occur when any Gcode job is running and only if it strays into a particular area?

Is the area fixed (relative to the table), ie defined by machine coordinates or is I relative to the job, ie work coordinates?

Craig

3189

Share Your GCode / Re: Wait for signal

« on: January 25, 2019, 01:28:31 PM »

Hi,
OK the code I have posted wont do at all, it would run every few milliseconds the entire time Mach is running and
affecting the behavior of the machine all the while.

I want it to wait when it is above one certain coordinate  x... y...z... and check one input only

So in fact you want this 'wait on signal' to happen only during a specific Gcode job? So any other Gcode job or MDI
commands or jogging would not be affected?

Craig

3190

Share Your GCode / Re: Wait for signal

« on: January 25, 2019, 01:13:05 PM »

Hi,
try pasting this code into your script:

Code: [Select]

local inst=mc.mcGetInstance()
local signalHandle=mc.mcSignalGetHandle(inst,mc.ISIG_INPUT4)
local wait= mc.mcSignalGetState(signalHandle)
if wait==0 then
mc.mcCntlFeedHold(inst)
else
mc.mcCntlCycleStart(inst)
end


Note that this code is pretty crude. If your input signal is low AT ANY TIME it will stop whatever job is running
and if it goes high the job, or any job loaded will start whether you wanted it to or not.

Is this want you want?. If so then you can put it into the PLC script and try it. If it is too crude then you need to think about
'under what circumstances do I want the job to pause while waiting for this signal'

Craig