[Verell]

Ahhh,
I understand what you're planning to do. Just present the PMAC as a pulse/direction controller to MACH3.

That really won't take advantage of the PMAC's ability to do things like S-curve accelleration/deceleration.

[josh591]

Mach3 has motor tuning built in already so it should be pretty smooth once it's running.

It's not ideal because something like

G00 X0. Y0. Z0.

would directly translate to PMAC as:
#1j=0
#2j=0
#3j=0

and I'm sure the PMAC NC code translator does this sort direct translation but the pulse translation method will also work and save me $1300.

If you buy it however, I'd be happy to try it out for you

[josh591]

I think this should work. Will try it when my breakout box gets here.


;M50 maps to input 0 -> x step pulses from mach

;M51 maps to input 1 -> x direction pulses from mach
;M52 maps to input 2 -> y step pulses from mach
;M53 maps to input 3 -> y direction pulses from mach
;M54 maps to input 4 -> z step pulses from mach
;M55 maps to input 5 -> z direction pulses from mach
; x axis

OPEN PLC 30 CLEAR
IF (M50=1) ; rising edge of pulse
IF (P50=0)
P50=1 ; set latch
IF (M51=1) ; direction pin
#1J^10 ; jog 10 unit
ELSE
#1J^-10 ; other way
ENDIF
ENDIF
ELSE
P50=0 ; reset latch
ENDIF



; y axis

IF (M52=1) ; rising edge of pulse
IF (P52=0)
P52=1 ; set latch
IF (M53=1) ; direction pin
#2J^10 ; jog 10 unit
ELSE
#2J^-10 ; other way
ENDIF
ENDIF
ELSE
P42=0 ; reset latch
ENDIF



; z axis

IF (M54=1) ; rising edge of pulse
IF (P54=0)
P54=1 ; set latch
IF (M55=1) ; direction pin
#3J^10 ; jog 10 unit
ELSE
#3J^-10 ; other way
ENDIF
ENDIF
ELSE
P54=0 ; reset latch
ENDIF

CLOSE


ENABLE PLC 30

[josh591]

I tested the code below and it works fine. My machine moves 1mm every 10000 counts and I can get .1um accuracy over 30cm. Had to set it to 100000 counts so that when I tapped the contacts I could see it move. As soon as I get my breakout box mach3 will be running and working great!

Pretty cool! I'm liking these PMAC driven machines!

;M50 maps to input 0 from -> x step pulses from mach3

;M51 maps to input 1 -> x direction pulses from mach
;M52 maps to input 2 -> y step pulses from mach
;M53 maps to input 3 -> y direction pulses from mach
;M54 maps to input 4 -> z step pulses from mach
;M55 maps to input 5 -> z direction pulses from mach
; x axis

OPEN PLC 17 CLEAR
IF (M50=1) ; rising edge of pulse
IF (P500=0)
P500=1 ; set latch
IF (M51=1) ; direction pin
COMMAND"#1J^10000" ; jog 10 unit
ELSE
COMMAND"#1J^-10000" ; other way
ENDIF
ENDIF
ELSE
P500=0 ; reset latch
ENDIF


; y axis

IF (M52=1) ; rising edge of pulse
IF (P520=0)
P520=1 ; set latch
IF (M53=1) ; direction pin
COMMAND"#2J^10000" ; jog 10 unit
ELSE
COMMAND"#2J^-10000" ; other way
ENDIF
ENDIF
ELSE
P520=0 ; reset latch
ENDIF



; z axis

IF (M54=1) ; rising edge of pulse
IF (P540=0)
P540=1 ; set latch
IF (M55=1) ; direction pin
COMMAND"#3J^10000" ; jog 10 unit
ELSE
COMMAND"#3J^-10000" ; other way
ENDIF
ENDIF
ELSE
P540=0 ; reset latch
ENDIF

CLOSE

[radioactive]

Did you ever get a copy of any documentation for the machine itself (not the controls)? I'm looking for some info on my machine YCM-40 (maintenance procedures, drawings, etc). Thanks

[Verell]

Sorry, all I've got so far is the control documentation.

[Verell]

...My understanding is that the PMAC is not specificly designed to handle G-Code directly, but has a set of subroutines that can be loaded into it's memory that are called by each block (line) of G-Code.

Actually, you can load configuration code that will process G-codes directly. Once in place the PMAC will accept G-codes & execute them.

...Here is a clip from a portion of the PMAC NC code (out of the PMAC Lite catalog)....

OPEN PROG 1000 CLEAR ; Prepare buffer 1000 for entry
RAPID RETURN ; G00 Rapid mode (N0 is implied)
N01000 LINEAR RETURN ; G01 Linear interpolation mode
N02000 CIRCLE1 RETURN ; G02 Clockwise circle mode
N03000 CIRCLE2 RETURN ; G03 Counterclockwise circle mode
N04000 READ(P) ; G04 Dwell for P seconds
IF (Q100 & 32768 > 0) ; P parameter specified?
DWELL (Q116*1000) ; PMAC specifies dwell time in msec
ENDIF
RETURN

Can you give me a pointer to the 'catalog', I can't figure out where you found the above example.

BTW, I just figured out that I actually have had 2 examples of g-code implementations all along:

1) A file containing examples motion control programs including an example gcode handler

2) My mill's configuration file which of course sets up the PMAC to run the mill, including processing G-codes.

If you still need them, send me eMAIL & I'll send you copies.

Now if I could only get this )@M) machine to work...

[vger]

Here is a link to the catalog...
http://www.deltatau.com/fmenu/PMAC%20CATALOG.PDF

Like I said, it's 20 meg in size, so takes a bit to load.

I have finally gotten my shed/workshop (12' X 16') put together and am out of the garage. Now I can work on the new machine.

My trip out of country was nice... cruise through the panama canal... ought to be on your bucket list. The ship had 18 inches of clearance on each side going through the locks.

Look for a PM with email addr. I would very much like to have a copy of the config file, and the example file. I'll just bet with some minor alterations I can make it work for mine. I may have a bit of work to do to get the other 2 axis to work (5 phase stepper drives) if I need them. Perhaps a PLC routine in the PMAC to drive the 2 drivers for them. That would give me 4 servo axies and 2 stepper axies.

Thanks
Steve

[Verell]

Ahhh,
I'd looked in the catalog & somehow overlooked that code example. It looks like part of the example I sent you.

Sounds like what you really could use is a fully populated (8-axis) PMAC with the ACC-8S stepper controller option.

BTW, just came across a PMAC G-code processing white paper with yet more examples:

http://www.deltatau.com/Common/suppo...%20Example.pdf

I've got another PMAC-LITE board, but am still fighting issues:
a) Configuration file loads w/zero errors, but verify against the config file reports 12 errors and then hangs.

It's unclear whether these are really errors, or just 'features' of PE. According to tech support, a) in particular may be due to the internal representatoin of the config data changing from the uploaded file(known feature).

b) If I download the donfiguration after uploading, I can verify against the downloaded file.

c) PE's dual ported RAM tests all end with 'checksum errors'.

d) My mill's control program now comes up & doesn't fault & exit. Even sees the control panel switches & jog switch. It doesn't report any errors, but also doesn't power on the servo subsystem!

My suspicion is that if I can get the servo subsystem to power up I might be well on the way to getting the mill fully operational. At this point I've finally got enough documentation and software tools so I should be able to figure out what's going on.

Did you know that PE can display the state of all of the PMAC connectors as nice connector pinout drawings!!!

Also, just found that I can launch PE from my windows application, so can get the machine into a particular state & see what the PMAC is seeing/doing!

Delta Tau ROCKs!!!
The more I learn about the PMAC, the more I'm amazed at the great job Delta Tau did with the original design, and how well the design has held up over time! The more I get into the hardware & software's design, the more right it feels.

The G-code processing mechanism is elegant! The fact that the handling of individual G-codes can be tailored to a specific machine and even updated with the machine's configuation file is a really nice scheme!

I'd love to know more about the history & background of the people & company that created the PMAC!

[Ron22]

Im a little late to this thread. I do work installing Delta Tau PMAC's on machines and repairing PMAC controlled machines.
If you want send me the file you are tring to down load and I can down load it into one of my PMAC and see what errors you are getting and why.

Ron

[Verell]

Very curious,
I started MICRO2 the window based machine control app. Which came up & let me power up the machine. Even gave me a Micropath Ready status. However, the servos don't respond to JOG commands even tho the MICRO2 window shows that a JOG was commanded.

Discovered a loose connector the machine's relay board. Connector delivers +24V for contact outputs. Plugged it in, but nothing changed(sigh).

From MICRO2 I started PE to examine the PMAC. The motor status windows indicate that the motors are not setup!

The obvious next step is to examine the configuration file to see if it's setting up the motors.

[Ron22]

Try this.

Then open PEWin
In PEWin oepn a postion window.
Turn one of the motors by hand. Is it counting?
Try this for all the motors.
If they are not counting try typing
I100=1
I200=1
I300=1
I400=1
This tells PMAC that there are motors there.
Now see if you see the motors counting.

If not try to run the MICRO2 program and bring up the machine and see if it counts.


If you are seeing the motor count you have a good start.

KEEP HAND BY ESTOP
Then try and type
#1J/
This should "close loop" the motor on #1. If you try and turn it now you should not be able to. Becarfull it might run away when you try and turn it.

If that works you can try to jog the motor in PEWIN too.
Type #1j=1000
You should see it count in the position window.

I would try and get the motors counting and moving first then deal with the MICRO2 program.
UNLESS the MICRO2 downloads the config every time it starts. I have seen this in many applications.

Ron

[Verell]

EUREKA!!
I modified AUTOEXEC.BAT so that it did'nt startup Windows & MICRO2.

Started PE (old PEwin).
Gave these commands to the PMAC to zero out the config memory & flash copy:
$$$***<cr>
SAVE<cr>
$$$<cr>
It probably wasn't necessary, but it ensures there's nothing lying around.

Then loaded the configMPATH2.DAT:

$$$***<cr>
;Used PE's configuration menu to restore MPATH2.DAT:
<alt>C
R
selected MPATH2.DAT
restore reported zero errors.
SAVE<cr>
$$$<cr>

; Used config menu to save the current config to: NEWRSTOR.DAT
; Used config menu to verify config memory against NEWRSTOR.DAT
got zero errors.

; Verify of config memory against MPATH2.DAT hung again. I think this is because PMAC stores things internally in different format.

Used ^C to get out of the hung PE.

Powered everything off, then powered up, started PE & was able to again verify config memory against NEWRSTOR.DAT w/o errors.

Powered up the servo system.

Opened PE's motor position counts window
Enabled the X, y, & Z axis motors:
I100=1
I200=1
I300=1

All 3 respond to the handwheels with reasonable counts.

Closed loop on X with #J1/
Yup, can't turn X axis handwheel w/o a LOT of effort & it wants to return, so the servo is powered up & working!

Tried Y axis and could turn motor. - not a big surprise as Y axis wasn't working when all this started.

Z-axis resists turning, so believe good.

Opened PE's Jog window.
Could Jog X-axis in both directions servo is definitely working!!!
but couldn't jog Y - reasonable results as it was bad before my PMAC troubles began.


Brought up Windows & MICRO2.
eXAMINED MOTOR I variables - they're mostly radicaly changed from what they were before starting MICRO2.

I think MICR02 is eithr trashing the config memory, or else is loading a junk config file from somewhere when it starts up!!! Time to go wading into the MICRO2 documentation for clues.

If it gets too frustrating, I can take a voltmeter & go figure out why the Y axis servomotor is't responding.

[Ron22]

EUREKA!!
I think MICR02 is eithr trashing the config memory, or else is loading a junk config file from somewhere when it starts up!!! Time to go wading into the MICRO2 documentation for clues.

Sounds like the MICRO2 is downloading the config file every time it starts. I have seen alot of programers do this. Search the hard drive and make sure thet is not another MPATH2.DAT floating around that MICRO2 is downloading.

Ron

[Verell]

I've already done that, there are 3 copies of MPATH2.DAT, all identical, and all match the 4th copy that's in a .ZIP file. (There are 2 backup directories that got created when new versions of various pieces were installed.)

I think a file with some other name is getting loaded & causing the problem. I'm going to look for files with a recent modified timestamp and inspect their contents.

[Ron22]

Sounds like you ahead of me already.
The file might not have a modified time stamp if it just read in.
You could just looking at files with not pad and see if anything looks like a congif file.
I have also seen 1 place where they hard coded the config into the program.

[Verell]

The MicroPath documentation says that if the PMAC has lost it's configuration memory, it will reload it from the MICRO2 directory using config file name specified in MICRO2.INI, specificly:
StartupFile=MPATH2.DAT

It also says it will report needing to do the reload (which it isn't!)

One thing about the PMAC setup is still bothering me. It has the Option 2 dual ported RAM card. I'm not positive I've set that up correctly with PE.
I'm pretty sure the RAM should be at the 8K range of PC addresses being setup in CONFIG.SYS with this command:

DEVICE=C:\DOS\EMM386.EXE RAM X=D000-D3FF

I'm using PE to setup the base address to : D000
(It won't take D00 which would think would be the sector address?)
Other dpram settings I'm using are:
24 bit addresssing (it's a 486-66 system).
8K ram size. (how can I tell from the card which size RAM I have? Couldn't find anything in the DP ram manuals to tell me how to differentiate the two cards.)

When I make the above settings, then select either configure or test there's a brief delay followed by a'checksum error'. I can't find much about checksuming in the 0ption2 manual.

I have 2 option 2 cards, and both behave the same way.

If I'm not getting the dual ported ram configured the way MICRO2 expects it to be, I'd think that might account for the problems I'm having.

It looks like I can turn off MICRO2's dual ported ram support. I'll try that next. If that doesn't work I"m out of ideas!

[jalessi]

This is a good read:

http://74.125.95.132/search?q=cache:...ient=firefox-a

Jeff...

[jalessi]

http://74.125.95.132/search?q=cache:...ient=firefox-a

This link has more information.

[Verell]

Here's all I've been able to find in the PMAC documentation about telling DOS where the DPRAM addresses are:

Note: We recommend using a base address of D400 for DPRAM. This have proven to work properly in most computers. Also, we also recommend that you modify your CONFIG.SYS file where you have your high memory manager (such as DOS' EMM386.EXE) to exclude the memory range that DPRAM will occupy to prevent possible conflicts with other device drivers/memory resident programs.

For example, if you DPRAM base address is D400 and you are using DOS' EMM386.EXE, then add the following to the line in CONFIG.SYS referencing the EMM386.EXE:

device=\dos\emm386.exe rem X=D400-D7FF
Begin Pattern

'rem' is not a valid input to EMM386, so I believe the 'rem' just before the X=D400... should be 'ram' which is a valid input.

The corresponding line from my CONFIG.SYS is:

DEVICE=C:\DOS\EMM386.EXE RAM X=D000-D3FF

Which reserves an 8K space starting at D000 in the PC's address space for a device ram. This just about has to be where this system expects the DPRAM to be.

I"m assuming that MICRO2 has to be setting up the DPRAM base address at some point, as MPATH2.DAT sets up:
WX$78A,$000000 <- DPRAM base address.
WX$78B,$000060 <- NO DPRAM (would be $E0 to enable DPRAM).