Hello Guest it is June 08, 2024, 11:44:19 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 - striplar

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 »
81
Mach4 Plugins / Galil plugin compatibility
« on: July 19, 2019, 02:39:04 PM »
I've had an email exchange with Galil about what motion controller they could supply to allow me to use my Linear Scales on my 4-axis mill. Currently the system uses a SmoothStepper and backlash compensation driving AC Servos.

They suggest using their DMC 41x3 motion controller but they don't know if this is compatible with a Mach4 plugin.

So the question is whether there is a Mach4 plugin that will work with this unit? If there isn't, would someone be willing to update the Mach4 plugin so this could be made to work?

I've done a fair bit of research, and I can't find any motion control product that close the loop with linear encoders and Mach4. Maybe someone knows different? My current setup with AC servos closes the loop with the leadscrew, but that's only half an answer. What's needed is a proper solution to this more tricky but much more satisfactory solution to dealing with backlash.

82
HiCON Motion Controller / Linear scales in dual loop feedback system
« on: July 19, 2019, 09:42:10 AM »
I posed this question directly to VitalSystems but got no reply....

"I have a system running Mach4 connected to a CM106ESS Smoothstepper breakout board via LAN with SureServo AC Servos using Step & Direction pulses, as if they were Stepper motors. However, I have Linear scales on all three axes and I'd like to close the loop with those instead of just having the closed loop on the leadscrew.
Do you have a solution that would allow me to take the output from Mach4 and feedback from the Linear encoders and feed the AC Servos with Step & Direction pulses or Modbus?

So to recap, the PC talks to the CM106ESS board which handles the I/O for the drives, spindle and limit switches. The SureServo AC servo takes the Step & Direction pulses and closes the loop with the rotary encoder which is integral to the drive motor.
I have Newall microsyn 1micron linear scales on each of the 3 axes but these are currently unused.

The aim is to use the linear scales to overcome the backlash issues which limit the accuracy of the current setup, even though backlash compensation is enabled.

I've attached the manuals of the components mentioned above so you can see in more detail what I'm currently running. (note:- I can't include these here because they're too big for the Forum)

Ideally I'd just plug a board in place of the CM106ESS which would take the commands from Mach4 via Ethernet and allow me to connect the AC Servos via Step & Direction or Modbus as well as the Linear encoders to close the position loop.

Perhaps you can tell me if this is feasible and what I would need to buy to implement it."



I've been communicating with the suppliers of the Galil motion controller and that does look like they might be able to help, but it's mighty expensive. Their solution involves controlling the SureServo using +/-10V analogue signals so they can control each element of the control loop without the SureServo controlling the motor position. In other words, the SureServo would be a torque control system, with the position being controlled by the outer loop and the linear scales.

Any assistance would be greatly appreciated

83
My guess is that it's an ESS problem. I've posted my log on the Warp9TD forum where it disabled following a load file/display toolpath event, so hopefully that will provide clues.

I think the ESS momentarily disables the drive occasionally but not long enough to latch it permanently off. During that time, pulses are still being output so they're lost and you end up with an offset. This is my speculation, but it fits nicely with the fact that there is definitely a problem with random disable events and sometimes a loss of position.


84
This has happened several times recently. I don't know if this is a Plugin issue with the ESS or whether it's an issue with Mach4. Perhaps this is somehow related to a watchdog not being refreshed during the regeneration?

85
Many thanks to Dazthegas for providing a simple one line MDI solution which I've used daily for the past month or so. It does exactly what I used the Mach3 one for and it's so much more convenient than the multi-line MDI on Mach4.
I've kept the tab for the Mach4 MDI just in case I ever want to do a multi line command. I thought it was safer to strip out the Cycle Start from the combined button and add one for the MDI inside the tab which I think it much safer.


86
It is not a 32 vs. 64 bit thing.  It is a processor/memory thing.  Mach 4 does things differently than Mach 3 did on the file loads.  The capabilities of the interpreter are far more advanced and requires a LOT more switch code.  Thus it does take more processor power to generate the tool path.  The newer builds will be an improvement in this regard, as I optimized it as much as I could. 

With the latest build, on my desktop machine, I can process 1000 lines of G code per second or 1 G code line per millisecond.  Now, my Atom board WILL NOT do this.  :)

The files are memory mapped.  This enables files that are far larger than the 32 bit address space.  However, if your machine is swapping memory to disk, well...  it is GOING TO BE SLOW.  I agree that 8GB of RAM is not sufficient for a Windows 10 machine.  Anything less than 16GB is uncivilized. 

If you change an offset, you MUST regenerate the tool path.  We don't auto regenerate because you may need to change several offsets and would then have to wait on each offset to regenerate the tool path. 

Steve

Is there any progress on this? I'm going to be doing some 3D work soon and the display takes over a minute to display the tool path on even smallish finishing paths.

Mach3 instantly shows the path at the new DRO location when you change it. You don't need to redraw the whole tool path when the DROs change, only the crosshairs that show zero. Why can't this be done for Mach4? I use this a lot when trying to place a profile on a sheet of material. It's a pain to have to keep refreshing and waiting to see where the cutter is currently located.

87
If there isn't going to be any further development on the plugin, would you consider releasing the source so I can make some changes myself? At the moment it's unusable for my system due to the way it handles the jog increments (as detailed in earlier posts), something that I'm sure I can fix.
It's a shame to have the pendant and not be able to use it.
Thanks,
Roger

88
Mach4 General Discussion / Re: Flickering Feed and Spindle RPM DROs
« on: June 02, 2018, 03:12:57 PM »
Hi Chad,
I haven't changed that much really, and nothing that involves the Jog and Spindle speed DRO. This is something that was wrong on the default screen set. I'll see if I can configure the original unmodified version to run on my machine to prove the point.

I take a different view about the development of Mach4. There's so much time wasted by people trying to figure out how things work and what all the variables do the hard way. This stuff is at the fingertips of the developer, and frankly I think it's just poor discipline not to document it.

Hi Allen,
No, there's no wired spindle feedback. Maybe it's expecting there to be a sensor? To be honest, I just need to see the RPM being output so I'll probably just change that. The same thing goes with the Feedrate, perhaps they are some sore of live value?

89
Mach4 General Discussion / Flickering Feed and Spindle RPM DROs
« on: June 01, 2018, 02:31:54 PM »
I've moved this from my other thread since it's a separate topic...

The Feedrate and Spindle realtime DROs on the Mach4Mill screen both have the same issue. All the time the machine is moving and the spindle is running, both of these flicker all the time, mostly reading zero, but you can just make out that they're also flashing up the correct values from time to time.

The dro144 component has DRO Code set to Current Feed Rate, and the droTrueSpindle component has DRO Code set to Spindle True RPM


I've searched through the ScreenScript for the component name and also anything to do with the words DRO and feed and there's nothing in there that I can see that's overriding the value being seen.

So my guess is that this is another bug and the variable is repeatedly set back to zero for some reason.

I'm using an ESS, so maybe that's somehow involved.

I've looked in dignostic->Regfile to see if I can see a variable there that represents this value, but I don't see one or anything flicking.  Again, a lack of documentation about these variables makes it difficult to check something like that.
I can see the first #variables but I have no idea whether it's one of those or not.

Any ideas how to fix this?

90
Mach4 General Discussion / Re: Simple one line MDI required
« on: May 31, 2018, 03:55:07 PM »
It ignores anything you type and press enter if the previous command isn't complete which is fine


I have given you the bare min to get you started, consider adding to the code things like if the controller state is not idle disable the ability to execute another command, as for clearing any control of txt you can use the scr. api commands to do this.

DazTheGas
Thanks Daz, will do.

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