Ultra 100, Parameter change through ASCII output of 5/03???

[arpus4KM]

So, i've hit the deep end.

customer has a 25 year old machine (not being replaced anytime soon). Its basic operation has a sequence that requires them to change the registration position of an ultra 100 (1398-ddm-09x). The program is taking an input number, converting to hex, converting to ascii, then sending the string through chan 0 over rs232 to the J5 port of the drive.


I've set up everything I can see to monitor and I can't for the life of me tell whether or not the commands are wrong or theres nothing being communicated to the drive to change the length of the registration.


Ultramaster was set up and communicating, Changing the numbers there works fine

I can monitor the rs232 ascii output from chan 0 using a tripplite keyspan and see that it is sending out the ascii codes at the specified interval.


What I don't know and need to know, is what are the commands that the drive can take, and are there any parameters that need to be set for the drive to take a new length commands in through its J5 port... Was there some handheld device that did this plugged into the J5 port and the original engineer just reverse engineered the output commands from the handheld or something?

Never seen this before, and I'm just determined to understand how to get it working again at this point moreso than try to sell them a new system.

 

[Steve Bailey]

The only Ultra system I put together used a Red Lion HMI for what you're doing. It was also my first project using a Red Lion HMI. I chose it because they included the Ultra protocol in the list of choices. As best I recall there wasn't anything special I needed to do on the Ultra to set it up to receive commands from an external source. I do remember that I had separate cables for communicating from the HMI and for communicating from UltraWare, so maybe there's a problem with the cable your customer uses for normal operations and the one you used for comms with the drive.

I'll look and see if I can find the protocol description manual. The laptop I was using back when I did that project has long since died.

 

[arpus4KM]

The only Ultra system I put together used a Red Lion HMI for what you're doing. It was also my first project using a Red Lion HMI. I chose it because they included the Ultra protocol in the list of choices. As best I recall there wasn't anything special I needed to do on the Ultra to set it up to receive commands from an external source. I do remember that I had separate cables for communicating from the HMI and for communicating from UltraWare, so maybe there's a problem with the cable your customer uses for normal operations and the one you used for comms with the drive.

I'll look and see if I can find the protocol description manual. The laptop I was using back when I did that project has long since died.

I was leaning towards that on first glance too.

I used a personal cable to get connected, then used the cable in place to connect as well, also checked the pinout.

The thing I wanted to verify was that the drive was able to accept commands, so I wanted a good list of commands I can send using PuTTy and watch it change on the fly, then I can either rule out the drive or the cable as the problem.

 

[Steve Bailey]

I can't remember if the display on the drive will show an error code if you try to send it a command it can't parse.

 

[drbitboy]

rs232 to the J5 port of the drive.

Maybe it does not matter, but the manual (here) says J4 for registration indexing, but maybe J4 and J5 are equivalent?


I would try to see what the SLC is sending to the Ultra by connecting the SLC to the RS-232 port on the PC and using something like PuTTY or hyperterminal (if that still exists).

There are extensive serial diagnostics in that manual.

 

[arpus4KM]

Maybe it does not matter, but the manual (here) says J4 for registration indexing, but maybe J4 and J5 are equivalent?


I would try to see what the SLC is sending to the Ultra by connecting the SLC to the RS-232 port on the PC and using something like PuTTY or hyperterminal (if that still exists).

There are extensive serial diagnostics in that manual.

Yep, I've been there already, used a tripplite keyspan 19hs to monitor the incoming and outgoing, and i could see the ascii coming out of the channel 0 dictated by the user settings in the config.



It could be outputting "Make me a banana split", but that's not a valid command for an ultra 100






The registration indexing works fine, it will index when given an input to do so. Changing the registration length internally through the channel is proving to be the bear.

 

[drbitboy]

It could be outputting "Make me a banana split", but that's not a valid command for an ultra 100

I don't understand: with PuTTY or hyperterminal, you should be able to see what the SLC is outputting, and whether it matches the string that the SLC code says it is sending.


?

 

[arpus4KM]

I don't understand: with PuTTY or hyperterminal, you should be able to see what the SLC is outputting, and whether it matches the string that the SLC code says it is sending.


?

It matches whats being sent by the SLC. I still don't know what any valid ascii inputs are for the drive.

 

[arpus4KM]

My goal is to use PuTTY and be able to see that the commands being sent properly, will be taken by the drive so I can eliminate those as the problem.


to be clear, the tripplite rs232-usb adapter has a built in terminal viewer that displays the same you would see with PuTTY and Hyperterminal, but can't enter commands directly in it that i know of.

 

[arpus4KM]

Im not at the site anymore, but I set up an emulate on a com port to show data passing out the com port like it should.

I didn't write these initial commands, so I am hoping they weren't modified somehow between when it last worked and where I'm at now.

even if I grab the data right as it touches the pins of the J5 port on the ultra 100, i still have no way to verify that the drive is receiving them unless it communicates back somehow. I don't remember ever seeing any receive signals from the drive either.

 

[Steve Bailey]

You might want to try downloading Crimson software from Red Lion. It's free. They list the Ultra serial protocol as one of their choices. Crimson includes an emulator, but I'm not positive if the emulator will communicate with an external target. If it does, set up some tags that read from and can write to addresses in the Ultra, put your sniffer on the serial port and see if Red Lion's character string matches what comes out of the SLC.

My experience is with an Ultra 3000, not the 100. However, I don't think Rockwell would have changed the serial protocol as they introduced newer models. At most they would only expose more addresses and possibly add additional commands.

 

[drbitboy]

1) Is there no documentation of the serial protocol? I guess the answer is no, otherwise you would not be asking the question.

2) Can the PC communicate with the Ultra via RS-232, e.g. via the Ultra Master Software? If yes, is it possible to capture those comms and compare them to what the PC captures from the SLC?

Sorry for being so slow and asking Captain Obvious questions, but this kind of thing is usually simple, or at least straightforward.

 

[Steve Bailey]

There is a description of the protocol in the manual I posted in post #4. While that manual specifically is for the Ultra3000, I'd be surprised if it didn't also apply to the Ultra100.

 

[drbitboy]

There is a description of the protocol in the manual I posted in post #4. While that manual specifically is for the Ultra3000, I'd be surprised if it didn't also apply to the Ultra100.

OP appears to be sending the string

:001B500FFFFF023A5<CR>

​

From here, that would appear to comprise the following elements:

Start   Address   Parameter   Function   Data       Checksum   End
[COLOR=darkred]:[/COLOR]       [COLOR=Red][B]00[/B][/COLOR]        1B5         [COLOR=blue][B]0          [/B][/COLOR][COLOR=Magenta]0FFFFF023[/COLOR]  [B][COLOR=sienna]A5         [/COLOR][/B]<CR>

Parameter 0x1B5 is not in the manual @Steve Bailey provided, but that may be neither here nor there as this is a different Ultra model.

What is interesting is that the Function is 0, which from here seems to be [Read working value]. I would not expect the Function codes to change between models, but with that assumption it seem odd that OP says they are trying to

to change the registration position of an ultra 100

Wouldn't that be a "Write working value?" Or is the command shown in the image OP provided attempting to read the value back after having read it?

 

[Steve Bailey]

There seems to be a disconnect between the manual I cited and the data provided by the OP. The manual defines a four-character command string, while the ST13 file seems to indicate a five-character command string.
Looks like we need the reference manual for that specific Ultra model. I found one for the Device net version of the Ultra 100, but not for a serial communications version.