VR Milling softare - Practical improvements to the 4th axis

[Paul Badger]

There are three issues that I would like to bring up as they pertain to using VR milling with my compact 1000 machine.

1. The operation of the 4th axis-- As it has been established, the VR Milling software assumes that the 4th axis is an angular axis and therefore makes some calculations about the angles and will only display and drive the axis between 0 and 360 degrees. This is a obstacle to operating the machine. For example if I want to place the 4th axis on the Z-axis for operation as a "robotic wrist" or as an extruder, I cannot write G-CODE to make the machine behave as I intend. Perhaps a parameter can be implemented on the parameter screen that allows the 4th axis to behave as an nearly "endless" linear axis.

2. The designation of the 4th axis-- Many 3rd party software packages can generate G-Code, but the 4th axis can be output as "D", "E", or even other letter designations. Since the VR Milling software allows the 4th axis to be recognized as "A","B",or"C" it seems that it would be an easy alteration to allow other designations. This would greatly hep me as I would not have to do a global search and replace through thousands of lines of code.

3. The exclusive use of "(" as a comment character. Again, many 3rd party software packages that generate G-Code utilize the semicolon ";" as a comment character. It would seem that the utility of the VR Milling software could be improved to allow this. It only serves to improve the software by making it as universally compatible as possible.

Thanks-- Paul

[Denford Admin]

Thanks for the comments, it'd be interesting to see what you're trying to do with the machine so we can help...

There are three issues that I would like to bring up as they pertain to using VR milling with my compact 1000 machine.

1. The operation of the 4th axis-- As it has been established, the VR Milling software assumes that the 4th axis is an angular axis and therefore makes some calculations about the angles and will only display and drive the axis between 0 and 360 degrees. This is a obstacle to operating the machine. For example if I want to place the 4th axis on the Z-axis for operation as a "robotic wrist" or as an extruder, I cannot write G-CODE to make the machine behave as I intend. Perhaps a parameter can be implemented on the parameter screen that allows the 4th axis to behave as an nearly "endless" linear axis.

Can you give some detail as to how you'd like it to work ?
How would you ask it to rotate endlessly ?
How would you specify the feedrate/surface speed or would it wan't to be specified as RPM ?

2. The designation of the 4th axis-- Many 3rd party software packages can generate G-Code, but the 4th axis can be output as "D", "E", or even other letter designations. Since the VR Milling software allows the 4th axis to be recognized as "A","B",or"C" it seems that it would be an easy alteration to allow other designations. This would greatly hep me as I would not have to do a global search and replace through thousands of lines of code.

You might think it's easy to allow any old letter but XYZ ABC UVW are the standards for 3 axis machines. A is the rotary axis around the X, B around the Y and C around the Z. When you think about it a lot of the other letters already have uses anyway... D is used for tool definitions, F is feedrate, G is gcode, H is tool length, I, J, K is arc centre etc etc..

3. The exclusive use of "(" as a comment character. Again, many 3rd party software packages that generate G-Code utilize the semicolon ";" as a comment character. It would seem that the utility of the VR Milling software could be improved to allow this. It only serves to improve the software by making it as universally compatible as possible.
Thanks-- Paul

I think adding ; would be easy to implement but I wonder if it's not easier to change the g-code post processor (which is designed to be altered) ?
Which symbols would you like to see and which are standard in other systems ? // ; !-- '

[Paul Badger]

Thanks for the comments, it'd be interesting to see what you're trying to do with the machine so we can help...
Can you give some detail as to how you'd like it to work ?
How would you ask it to rotate endlessly ?
How would you specify the feedrate/surface speed or would it wan't to be specified as RPM ?

In short I have attempted to convert my Denford Compact 1000 into a 3D printer. I have built a tool mount that attaches to the Z-axis which has an extruder hot head mounted at the bottom. I have built a circuit that drives a stepper motor from the discrete 4th axis output on the Baldor NextMove card. This circuit allows for the possibility to drive up to two independent extruders by switching between two drivers using an output signal from the Baldor card. At this point though I have only attached one extruder. I am using the parameter screen in VR Milling to set the number of steps to extrude 1mm of filament, but of course VR Milling interprets values on the A axis as angles. To set feedrates, I simply specify Max feed rates in the parameters and set feed rates in GCODE for each axis. Since the length of filament extruded can be very large, the GCODE generated contains commands to drive the extruder axis in ever increasing absolute values (A1.000 would specify an extrusion of 1mm, A2.000 would specify an extrusion of an additional 1mm). At the end of a short program the length of extruded filament can exceed 8000 mm. So when I say that I would like the 4th axis to rotate "endlessly" I am suggesting that the limitations in the parameter screen of -9999 to 9999 may prevent me from printing larger objects. It was my belief when I started this exercise that the size of the build platform on the Denford Compact 1000 would allow me to print some fantastic objects. Properly set up and adjusted, I could have nearly 12" x 9" x 6" of volume which is fairly large.

When I suggested that additional axis be allowed I specifically had the designation "E" in mind for my extruder as this is standard for 3D printers. I can understand the convention used and know that my application is slightly outside the scope of usual milling applications. You are correct, I can use a post processor to change both "E" to "A" and to change comment characters such as ";" to "(". I was hoping to avoid doing that if possible. These two issues are secondary to the behavior of the 4th axis.

As a side note, I am going to try to build a tool head that allows me to mount a plunger operated Eppendorf pipette and dispense volumes of reagents into a wellplate. I think that the issue with the 4th axis may also have a negative effect here too.

[Denford Admin]

I see what you mean

It's something we've thought about adding to the machines in the past but think that it's too much of a 'black art'.
Apart from needing a hot end to extrude nicely, the model needs to be kept warm or it will split as the bottom cools whilst printing the top.
Heated beds and/or chambers are a necessity on build areas larger than say, 100mmx100mm
The issue of extruder values getting out of hand is usually dealt with by reprap software by resetting the E value to 0.0 after each layer...you could try a G92 A0 from VR milling (but I'm not sure if it works)

As it sounds like you've done quite a lot of R&D I would suggest looking at using the Baldor ActiveX (MintControls.ocx) and writing something fairly simple to control the machine from your own app in C, visual basic or Delphi.
This would be a good place to start:
https://www.baldor.com/products/motioncontrol/mintmt.asp
https://www.q-tech.hu/pdf/Baldor/MintMT% ... 0Guide.pdf
...we can always help if you get stuck with the concepts

[Denford Admin]

PS - this might interest you as a cheap hotend which could be restrofitted to a machine maybe ?
https://www.kickstarter.com/projects/135 ... inting-pen

[Paul Badger]

As it sounds like you've done quite a lot of R&D I would suggest looking at using the Baldor ActiveX (MintControls.ocx) and writing something fairly simple to control the machine from your own app in C, visual basic or Delphi.
This would be a good place to start:
https://www.baldor.com/products/motioncontrol/mintmt.asp
https://www.q-tech.hu/pdf/Baldor/MintMT% ... 0Guide.pdf

Thanks for the leads. That was my backup plan. As long as there are some examples on how to establish communication, handle exceptions, control the door and emergency stop, etc, I think that an interpreter might be easy to implement. It will be crude but hopefully functional.

It's something we've thought about adding to the machines in the past but think that it's too much of a 'black art'.
Apart from needing a hot end to extrude nicely, the model needs to be kept warm or it will split as the bottom cools whilst printing the top.
Heated beds and/or chambers are a necessity on build areas larger than say, 100mmx100mm

As far as I have seen, when printing using PLA there is much less need for a heated bed or heated chamber. There are loads of kits and personal machines that have build areas greater than 200mmx200mm which work without those luxuries. If you are working with ABS things become a bit messy.

The issue of extruder values getting out of hand is usually dealt with by reprap software by resetting the E value to 0.0 after each layer...you could try a G92 A0 from VR milling (but I'm not sure if it works)

That may help but I still seem to have a problem with the VR Milling software interpreting movements and then driving to that location in whatever direction it sees fit. I cannot understand how it determines the direction of travel. For example a test program I wrote had position commands such as

G01 A1.0000
G01 A2.0000
G01 A3.0000
G01 A2.0000
G01 A1.0000
G01 A0.0000
G01 A-0.5000

The first 6 commands all drove the stepper motor counterclockwise even though a positive direction is clockwise. The first three commands are in the positive direction and the next three are negative in absolute value. Oddly enough the last command which is negative in absolute value drove the stepper in a positive direction. This unpredictable behavior makes it nearly impossible to even tell how to start modifying my code to try to make it work.

[Denford Admin]

That was my backup plan. As long as there are some examples on how to establish communication, handle exceptions, control the door and emergency stop, etc, I think that an interpreter might be easy to implement. It will be crude but hopefully functional.

I really think it's the best way to get full control of the 4 axes and make sure they interpolate together properly.
The 4th axis works OK and wraps around for the code produced by our 4th axis software so we wouldn't want to make changes that may break that.

Handling the e.stop and door is taken care of in the Mint program which is pre-compiled (Compact1000.mex) and sent down when the PC host connects to it.
You can just keep that file as it is and only worry about connecting, downloading the .mex file, running the mint and then sending MA or VA commands (move or vector absolute)

[Paul Badger]

Handling the e.stop and door is taken care of in the Mint program which is pre-compiled (Compact1000.mex) and sent down when the PC host connects to it.
You can just keep that file as it is and only worry about connecting, downloading the .mex file, running the mint and then sending MA or VA commands (move or vector absolute)

I'm going to have to write the interface for the interpreter in some programming language such as C++, Visual Basic, or Delphi. It does not matter to me which language. Most of the information of the Baldor website is in reference to using the Mint language and their MintMX interface. If anyone has sample code for establishing communication using their ActiveX control via any language such as the ones above I would very much appreciate any pointers to getting started.

[Denford Admin]

If you install Mint machine Centre from the VR Milling 5 CD, the help has an ActiveX programming guide.
There are also examples installed with the program in:
C:\Program Files\Mint Machine Center\Examples\...
Delphi5
LabView6
VB.NET 2008
VC#.NET 2008
VisualBASIC6
VisualC6

[Paul Badger]

Handling the e.stop and door is taken care of in the Mint program which is pre-compiled (Compact1000.mex) and sent down when the PC host connects to it.
You can just keep that file as it is and only worry about connecting, downloading the .mex file, running the mint and then sending MA or VA commands (move or vector absolute)

Well, writing the interpreter has been harder than I had hoped but about what I expected. The documentation for the Baldor ActiveX control is sketchy at best. The best help and documentation comes from Mint Workbench Help, but that does a very poor job of fully documenting the methods and events of the ActiveX control. Baldor technical support has been good at answering my endless questions.

Now I have one that I am having trouble with. As implied above, if I download a compiled mint program to the NextMove controller such as the ones from Denford (Compact 1000 Pro_4Axis.mnt) some of the work is done for you. Handling the door is done and a few other things. But I am having difficulty releasing the brake on the Z-axis. Looking at the wiring diagram and the program above it seems that the brake is controlled from output #15. So using a command in my interpreter such as;

MintController.set_outx(15,0)

should set output #15 off and I should measure 0 volts on that pin. However it is not functioning as I expected. I combed through the mint code in "Compact 1000 Pro_4Axis.mnt" and could not find any other code that would stop this from working. Perhaps there is something that I am overlooking. The mint program establishes a state for the machine. I just want to enable the drives, home them, and start sending coordinates...

PS> For future reference for people trying to do similar things, the NextMove controller will not accept a compiled program file which has an underscore character "_" in the filename. That one took me a while to diagnose.

[Denford Admin]

I don't know how much you've changed of the compact mint but you should just have to call this.

Code: Select all

'Set the Z axis brake output  0=locked, 1=released
Sub SetBrake (state As Integer)
  If state Then Wait (500)  
  OUTX.15 = state And !INSTATEX.STOPSW
'  ?"Brake is ", state
End Sub

It is normally called from the safetycheck task which is looping all the time.
VRMilling sets comms location 36 in order to tell the mint that it is ready to go:

Code: Select all

Task SafetyCheck 
  COMMS(19)=0            'Initially say machine not safe
  Loop
[..cut...]
    
    DRIVEENABLE[ALLAXES]=COMMS(36) And !INSTATEX.STOPSW;
    'if connected and enabled and Brake is off then turn it on
    If COMMS(36) And !INSTATEX.STOPSW And !OUTX.15 Then
      SetBrake !INSTATEX.STOPSW
    EndIf
    ' if not connected and Brake is off, turn it back on
    If !COMMS(36) And OUTX.15 Then
      SetBrake 0
    EndIf    

It's also turned back on in the Stop Event, then released again when the estop is released.

You shouldn't really have to change much, if anything, in the mint. There will be nothing in there to prevent you from commanding moves from the host - just be aware that some COMMS locations will need setting up when you first connect (it's also worth having a delay on the host, after downloading and running the mint before continuing)