• Please review our updated Terms and Rules here

WANTED: Software for Unimation Puma 560 robot.

I don't want to sound like Mr. KnowItAll, but when you get the 'Load Val from Floppy' message, you have a VAL-II machine, if you just get the 'Initialize?' message, you have a VAL machine which keeps the OS in Eprom memory. There is no way you can reload VAL for these units. You would have to programm old TI Eproms (TMS2716).
Long story short: VAL and VAL-II are different animals, software and hardware are different.
I just got a new, or better old, VAL 560 and I have 3 VAL-II 760, one in working condition, one in rebuild state and one ... I don't want to go there, worst case it will help me with spare parts.

Questions always welcome!
 
Thanks for the info. I found out later that mine does not need the batteries... that's good. :D But someone also told me that the EPROMS are subject to "ROM ROT" and can loose the data over time... he suggested that I make a backup copy of them... so it's good to know that I need the TI (TMS2716) EPROMS. (I'll have to find a programmer and get some to do the backup.) I used to have a PROM programmer too... need to see if one of my Motorola buddies still has access to one. If so I'll copy them each to a HEX file and have it for anyone else that may need it... I imagine they are getting hard to come by.

Hey... while I'm here... someone said the second user port could be used to send serial commands to the robot directly... not via the VAL programming language. I've seen where people were running the machines with C or Visual BASIC directly... does anyone have information or manuals on that? It was like a 19.2K RS232 connection or something... much faster than the 9600 BAUD TERMINAL port.

Thanks,
Jerry
 
The TMS2716 have a slightly different pin out compared to 'normal' 2716. Either you got a somewhat old eprommer that can handle these or you build an adapter. I did go the adapter route and have backups of my system. It is a Val version 18.1B. If you need the files or have a different version, please let me know.
I addition to the OS eproms I did backups of all the other programmable ics (proms and microcontroller of teach pendant).

You still need batteries for your RAM if you don't want to load your programs from floppy all the time.
 
I don't have the floppy... and I suppose the batteries are still good because a couple of weeks after I last used it I can answer "N" to the init prompt and the programs and positions are still good. I'll have to see if there is some notice or something to indicate which version I have in the event you have the same one... then I could back up the files which would be great. We found a PROM programmer... don't know yet if it is the right type or not... need the time to look into that more.

I am interested in finding out what the Teach Pendant sends... I found the pinout... and I know it is just serial data... it would be nice to have the ability to program an Atmel or similar micro to act as a teach pendant... possibly with some function keys or special features. There is also an Accessory port... I found some documentation that says it is RS232 and can be used by an external computer... but I can't seem to find out exactly what is sent for control. It could be a command set like VAL, or it could be something more streamlined like J6200 to drive joint 6 to position 200... and so far... no way to find out.

Anyway... if you find any info on that it could be very useful!

Thanks,
Jerry

By the way... I have a beta G-Code converter working... and hopefully shortly will have a setup where you can convert a large G-Code (10,000 lines or more) and send to the PUMA as a stream. If I get that working... we can use the PUMA to carve 3D stuff.
 
...someone also told me that the EPROMS are subject to "ROM ROT" and can loose the data over time... he suggested that I make a backup copy of them... so it's good to know that I need the TI (TMS2716) EPROMS. (I'll have to find a programmer and get some to do the backup.)


Hi,
I don't know anything about "ROM rot," but I do know of a fellow up in Canada who can make you backup copies of those EPROMS. The fellow's name is Stephan, and he can be reached at info@hobbyroms.com.

His web site is http://www.hobbyroms.com/ (obviously).

I highly recommend this fellow. He will watch out for your special instructions, like if you specifically need TI devices. And, above all, his prices are amazingly low.

smp
 
Rom Rot

Rom Rot

I have heard of 'Rom Rot'. Most of the things I have heard were about UV-Eproms and some EEPROMS.
One time I had a instructor tell me that Gama rays from outer space, although rare, can strike the atoms in memory cells and cause them to degrade. I have not heard of PROM chips suffering the same fates.

Most memory loss that I have ever encountered was caused by static shock to chips.
 
Hi folks,
IT is amazing how a few years can slip by so quickly. I hve finally been allowed to return to working on my Puma robot arm. Of course when I finally got it all powered up it doesn’t work. It figures.
So here is what I am researching now. The CPU and Serial card seem to be working. When the system powers up, I see the boot message followed by the ‘Load VAL from floppy?” prompt.
The load seems to start properly, but the process fails on the 3rd block with a ‘Checksum error : 23”
message.
I am not running from an actual floppy, I am loading VAL from a PC serial port with a Floppy emulator. I tried a few backups of the original file just to make sure I didn’t have an actual ‘Checksum error’ in the file.
So now I am ticking through a list of Troubleshooting guesses. Anyone have any suggestions, I am all ears. I’ll post what I find. Right now I am checking for back connections on the boards and ways to test the information that is actually being sent to the serial port. Maybe I have a bad port?
P.S. My memory and serial cards were made by INSTEM as part of a short lived production run between 1972 and 1985. If anyone has any INSTEM card guide books or documents I would really like to see them. Some of the jumpers are similar to the digital PDP counterparts, but they are just different enough to make me uncomfortable making changes.
Thanks and sorry for the long absence.
-MIke
 
Hi and welcome back...

My first guess would have been a damaged / modified file where the block checksum does not match the calculated.
Second guess is a bad memory chip. As far as I remember you have 3 identical ram cards. What about trying to swap them to see if you can boot further. In order to do that you have to change the base address. There should be information about that in the electrical drawing set. If you don't have that, you can compare the boards and swap the settings. Just make pictures first and / or have everything well documented. If you want you can send me the pictures and I will see what else I can think of.

One other thing: how are the batteries doing? If they are weak, the memory starts acting 'funny'

H.
 
Last edited:
The batteries are good, I replaced them about 2 years ago. Still holding a charge.. I did swap the 'bottom' two memory cards with no effect. The dip switches on them had me scratching my head though. I'll have to post Pics. I don't have the electrical specs manual.


This is what I actually see when loading:
* VAL-II Boot B560C.2.3 15JAN91 *

Load VAL-II from floppy (Y/N)? y

Language for VAL-II error messages:
English(0), French(1), German(2), Spanish(3), Swedish(4)? 0

Robot serial #? 0063
123
23: Checksum error

Looking at the actual files I can see the blocks and after a lot of math they have the correct checksums. (for those following along: Add up all the bytes in a block except the last one. Strip off all but the last 8 bits. Invert it and then add 1. It should equal the last Byte in the block.
[For those of you playing along at home:
The Bootloader uses a 2's complement
checksum method.

Here is the actual first block from my VAL II executable file
is only 9 bytes long. There are 246(dec) zeros that fill the remainder
of the 255 byte block.
{01 00 08 00 EA F4 80 01 98}

Start of Block 01 {1}
Um - maybe block size? 00 {2}
Definitely block size 08 {3}
um - Dont know for sure 00 {4}
Actual data in block EA {5}
... F4 {6}
... 80 {7}
... 01 {8}
CheckSum 98
01 + 00 + 08 + 00 + EA + F4 + 80 + 01 = 268
268hex = 10 0110 1000bin
Take just the last 8 bits 0110 1000
0110 1000 Inverted = 1001 0111
Add 1 = 1001 1000 = 98hex
Checksum matches. (yea!)


Here is what I see on the terminal screen when I try to load VAL:
* VAL-II Boot B560C.2.3 15JAN91 *

Load VAL-II from floppy (Y/N)? y

Language for VAL-II error messages:
English(0), French(1), German(2), Spanish(3), Swedish(4)? 0

Robot serial #? 0063
123
23: Checksum error

Load VAL-II from floppy (Y/N)?

I am assuming the error is being kicked out AFTER the third block is loaded into memory.
The first two blocks are very short, only 9 bytes long with a lot of zeros.
Before each block the system must request the next block before the floppy emulator will begin sending again. So the communications must be working well enough for the first two blocks to complete. I am also guessing the Checksum calculation is working for the same reason.

I am using the ODT (@ prompt) to scan the memory for problems. So far I have found a lot of 8 bit data but very little that could count at actual Op-codes.
Again for the home audience:
To use the ODT Prompt (@)
type a memory address followed by "/" and the system will give you the value of that location.
Press (ctrl J) and the system will move to the next location.
To change a value type in the octal value on the same line and press return.
You can key in an entire program this way and then start the program by typing in the memory location followed by "G"
Typing R followed by 0-7 will display the CPU registers.
RS shows the (PS) register.. Not sure what the PS register is yet..
P resumes a program from the current location after a 'Halt' stopped it.

Right now I am trying to decode the meaning of the first two blocks. If the error takes place AFTER the third block, I would expect to see those 250 Bytes of data in memory somewhere. So far I have scanned from 0 through 171616 and I haven't found it yet. I am guessing that one of those two 9 Byte blocks at the start contain the 'Origin' location where the cost should load into memory. But I haven't been able to guess how to decode them yet.
Here are first 3 the blocks. Well some of them
Block 1: 01 00 08 00 EA F4 80 01 98 {lots of zeros}
Block 2: 01 00 08 00 CA F4 06 7F B4 {lots of zeros}
Block 3: 01 00 FE 00 00 A0 5F 00 18 00 EE 9C 00 ...... Ect
The 3rd block is FE bytes long and that is the one I am trying to find in memory.

I am running at 9600 baud and it has never been an issue before, but I might try lowering the baud rate to see if it helps, but that doesn't seem like the issue as the terminal and the first two blocks all seem to work properly.

Sigh. The quest continues.
But then, I think that’s what I like about these older machines.

-Mike
 
I am interested in finding out what the Teach Pendant sends...

I haven’t broke into the teach pendant communications yet. I do know the Main system sends a constant stream of data to the pendant. I think it keeps the display updated. IT seems like a lot of overhead, but the pendant is sometimes the only interface an operator has, so it might make sense.

The Serial pin out is important, but don’t forget the ‘Deadman’, Speed, and ‘E-Stop’ circuits.
The Deadman is a loop that lets the robot know it is safe to keep moving. Usually the pendant has a button on the side and a switch in the back. If the pendant is hanging up the back switch is held in, If the pendant is not hanging up, the operator has to hold in the ‘Deadman’ in order to keep the robot moving.

The Estop is a circuit loop through the whole system. Break the loop and everything stops. If you are going to have a virtual device, you could just loop these two lines through the connector I guess.

The final is a toggle switch that sets the move speed in the teach mode. Normally the robot will move slowly but flipping the switch will enable faster movement.

There is also an Accessory port... I found some documentation that says it is RS232 and can be used by an external computer... but I can't seem to find out exactly what is sent for control. It could be a command set like VAL, or it could be something more streamlined like J6200 to drive joint 6 to position 200... and so far... no way to find out.

The Accessory port is just a serial port on the system. You need to access the memory locations 776520 – 776526 to use it.
776520 Rcv Status register
Only 2 bits:
<6> R/W – Enable =1 / Disable =0)
<7> R - 1 = Ready to read. Cleared by Reading Buffer
776522 Rcv Buffer
16 bits ( yes 16!)
<7:0> 8 bit data
<11:8> - Not used
<12> Parity Error
<13> Frame Error
<14> Overrun Error
<15> Any error (set if there is ANY error)

776524 Tx Status Register
3 bits
<0> R/W - 1=Space mode. Create a space or Break signal.
<6> R/W – 1 = Enable
<7> W - Buffer Empty –or- TX complete

776526 TX Buffer
8 bits
<7:0> - Data to be sent
I can send you a sample program that shows how to access this port from inside VAL. Once it is set up, it is just a port that the VAL program can use for a printer, or any other Aux I/O you want.

To actually control the joins from outside of VAL you will want to use the ALTER mode. It requires another serial card. They are still out there on ebay. Adding another card you get another 4 ports. The SUPERVISOR and ALTER ports allow you to directly control the arm from outside. A small VAL program is still needed, but you loose all the Kinematics and frame tools of VAL so you will need to do all the heavy lifting in your own code.

I’ll get the materials I have together if you are interested in those also.

-Mike
 
Hi Mike,

A block always starts with 01 00, then 2 bytes length. Then in byte 5 and 6 you have the address in memory where the data should go. Then comes the actual data and the last byte is, as you already thought, the checksum.
The first two blocks write data to control registers in the PDP11: 0xF4EA = 172352 octal = KISAR5 and 0xF4CA = 172312 octal = KIDSR5 to map memory space around. I hope you don't want more details for that, otherwise I will send you the datasheet of the PDP11 ;)

The third block actually writes to RAM at address 0xA000 = 120000 octal. You might find the data there with ODT, but only if the mapping registers are still set correctly.
After a little calculating: the code will end up at 200000 octal start address in memory (in kernel instruction space). You would have to find out the mode you are running ODT in. If you can switch to kernel instruction, then the data can be found at 120000 octal (if KISAR5 is still 0x0180 or 600 octal)
You can find out more in the 'KDJ11-A_UsersManual.pdf' under memory management.

The floppy transfer protocol wraps this block data '01 00 .... crc' in its own frame, again checking for the right checksum. That just for your information besides everything else. Need details, send me a PM.

Just swapping the cards won't help since you would have to change the address jumper settings. If you don't do that, you actually didn't change anything besides the contacts on the backplane...

I saw the pictures on your website: http://theatronics.com/Memory_Card_Archive.php.

That's it for now, H.
 
Last edited:
Mike,

just for the record: Jerry has a VAL machine, not a VAL-II. There is just one additional 'accessory' port which is not supported by the OS. 'For future use', that's what the manual says. And there are no commands that would allow IO access to the actual UART.

Unless you modify the eproms there is no way to communicate to the outside world besides the floppy. And even the floppy has a slightly different protocol compared to the VAL-II / 'high speed' floppy we are dealing with.

H.
 
dang. That just makes me want to find a way to make it work.
I uploaded a VAL program to my projects site that 'pokes' an assembly lang program into memory that connects to the UART board directly through it's mapped memory location. Is there any chance the 'extra' port is connected to a 4 port card? I have a cleaner version of the program somewhere and I'll load it as soon as I find it.

Maybe the program could be modifyed to 'take over' the floppy port. Once the program is loaded, a simple (A/B) switch could be used to change the connectons. I just can't give up... sorry.

-Mike
 
Hazah!
Block 1 is [KISAR5] and it is loaded with 0x8001.
Block 2 is [KIDSR5] and it is loaded with 0x067F.
Block 3 begins loading at [0xA000]

It is so fun when things start to come into focus.

Yes, I will read the KDJ11 Manual. I am not as familliar with memory mapping for the PDP family as I should be.

Thanks again!
-Mike
 
Mike,

almost right. The numbers would be 0x0180 and 0x7f06, low byte first, then high byte. 0x0180 is 600 octal. That gets shifted left by 6 so it is 60000 octal. Add that to the actual address you want to access and it gives you the hardware address: 60000 octal + 120000 octal = 200000 octal.
Funny memory management: if you write 2000 octal to KISAR0 you would be able to access the exact same memory when you read write from 0 octal. 2000 shift left by 6 = 200000!
Each KISAR (0 to 7) is responsible for 20000 octal. KISAR0 = 0 - 17777, KISAR1 = 20000 - 37777 ...

Don't forget that you cannot map ram into the 4k IO space between 160000 and 177777.

Regarding the serial port of a VAL machine: there might be the possibility to load a custom program into ram with the 'dia' command. The only issue would be that you need to mark this area as used. Otherwise the OS would overwrite that as soon as the memory gets full. I don't know the exact memory management of VAL so that could get tricky. I do have disassembled VAL V18 which is running my old 560.
For the same system I wrote a memory test in assembler to be able to repair a bad memory card.
Did you ever hear about PDP11GUI? That is a great tool if you want to mess with ODT or write small programs.

H.
 
Last edited:
Does the memory offset take place even in ODT? I am still confused about the serial ports being mapped into the same area as ram. I just dont see how the system could boot and ask "Load VAL" unless that offset is put in place before the load starts. I will have to read more.
Isn't it possible to offset one memory card ON TOP of another one accidentally?

-Mike
 
I just read a little: ODT handles 22 bit addresses so you would be able to type 200000/ and it should get you the content of 200000 octal. The IO addresses must have the full 22 bit address, so 160000 - 177777 is moved to 17760000 - 17777777. I was wrong with the memory management in ODT, so don't worry about it.
The concern about overlaying one card on top of another is plain hardware. For testing you should be able to run the system with just one memory card but it has to be the one that starts at 0 octal.

The only difference between your cards and mine is SW1-1. Yours are turned off, mine is on. I have no idea what that would do. I might just drive over to my 761 and test it.

Something else that's interesting: offset 0x2300 in the VAL-II file you have another place where the offset is changed to 0x01ff. That shifted right by 6 = 77700 octal. Add the next virtual address of 0xa038. That gives you 217770 octal.
When you go through the file you will find several places where they rewrite the offset.

H.
 
Corrected.
Block 1 is [KISAR5] and it is loaded with 0x0180.
Block 2 is [KIDSR5] and it is loaded with 0x7F06.
Block 3 begins loading at [0xA000]

I have been looking all over for the registers [KISAR5] and [KIDSR5].

I did find a mention of the address 172352, but it was called [PAR5]. The remark with it said ‘handler addresses’ Along with it was address 172354 [PAR6] that had something to do with ‘ibid, TSX’ ?

Where did you find the terms KISAR5 and KIDSR5 ? I have some manuals in PDF image format so I can’t scan them for actual words, I have to flip pages and search for details the old way.

-Mike
 
Argh. Computers are frustrating.
Ok, I was checking the signal and I found the data seemed to be fine up to the UART.
While I was checking out the Serial card, I noticed that one of the jumper wires (wire wrap) was a little long and looked like it had gotten caught on something. I eventually removed all the wire wraps on the settings pins and re-wrapped them to 960 Baud
0 = N Teach Pendant
1 = N Floppy Drive
2 = N External Accessory Port
3 = EX (External signal selects between 300 and 9600 baud for Terminal)
Now the program seems to load, but right after the last byte is sent, the system locks up.
Even an ‘INIT’ will not bring it back. I hear the safety relays chatter some times.
I am going to look real close at the power supply. If this turns out to be a weak 5V line I am going to be so frustrated.

-Mike
 
Back
Top