rharmon@sandia.gov

All, Once again I want to thank everyone who chimed in to help me figure out this communications issue. I have attached a small project file that communicated with the Tripp-Lite SmartOnline UPS. If Tripp-Lite tells you to use communications protocol 4001then this software should work. To say again, Tripp-Lite was not helpful. The protocol document they sent me in no way works. Not even close. What was helpful. 1. Input from you guys who chimed in here. Huge help... Thanks. 2. https://github.com/networkupstools/nut/blob/master/drivers/tripplitesu.c although I don't do C, reading the information here was very helpful 3. The Tripp-Lite Programmable MODBUS Card Owner's Manual. A colleague at work found this document and although it doesn't translate perfectly it was helpful. 4. My bullheadedness and refusal to give up when I knew it should be able to be done. So obviously without input from Tripp-Lite I can give no guarantees on the accuracy of this code. I feel it's right. If anyone wants to try it and let me know how accurate you think it is... That would be helpful. Even better yet if you find errors please let me know. Thanks again, Bob Harmon Tripp-Lite Project.zip

All, Once again I want to thank everyone who chimed in to help me figure out this communications issue. I have attached a small project file that communicated with the Tripp-Lite SmartOnline UPS. If Tripp-Lite tells you to use communications protocol 4001then this software should work. To say again, Tripp-Lite was not helpful. The protocol document they sent me in no way works. Not even close. What was helpful. 1. Input from you guys who chimed in here. Huge help... Thanks. 2. https://github.com/networkupstools/nut/blob/master/drivers/tripplitesu.c although I don't do C, reading the information here was very helpful 3. The Tripp-Lite Programmable MODBUS Card Owner's Manual. A colleague at work found this document and although it doesn't translate perfectly it was helpful. 4. My bullheadedness and refusal to give up when I knew it should be able to be done. So obviously without input from Tripp-Lite I can give no guarantees on the accuracy of this code. I feel it's right. If anyone wants to try it and let me know how accurate you think it is... That would be helpful. Even better yet if you find errors please let me know. Thanks again, Bob Harmon Tripp-Lite Project.zip

I will... Thanks to everyone who helped... I've made a lot of progress... In the end I think try to write up something to help others who run into Tripp-Lite road blocks...

Perfect... Don't have to worry about some data there messing up my parsing... You guys are amazing....

LogMAN Interesting... I like it, then my data is in an array that I can index for the values I need Any concern about the double semicolons? Bob

I have a question on how you guys deal with parsing a data string. The data string looks like this ~00D0370;0;0;0;;1;0;0;1;0;;0;0;0;0;1;0;0;0;1 I understand the ~00D is telling me the string contains data and the 037 tells me the length of the data string. I could easily use String Subset to select the variables I want, or Match Pattern to drop the semicolons in the string. I'm sure there are hundreds of methods to accomplish this. If you have a better method I'm all ears. One thing is worrying me... where they have the double semicolons... Could I ever expect a value to end up between the double semicolons? Because that would totally mess up my parsing. How would you deal with the double semicolons? Thanks, Bob

A huge thank you to all who have chimed in here. Here is an update as to where I'm at now. At least one of the USB to RS-232 converter cables work. I have been able to get some communications going with the UPS. I used some software that allowed me to monitor the comm port. While running the Tripp-Lite software I was able to see the protocol the UPS was using. Needless to say it differed in large ways from the document Tripp-Lite supplied me. I was angry at first but I'm over it. In another post I started "My Lack Of Knowledge On Hex" Rolf Kalbermatter sent me to a site https://github.com/networkupstools/nut/blob/master/drivers/tripplitesu.c which has some code (C code) that someone uploaded. Between all the help you guys have given me and the code I think I'm going to be able to get something going. Well See. But honestly thank you guys... You are a huge help... Bob

Everyone... Thank you I contacted the company today honestly tech support is trying to help but they don't understand the communications portion so they can't really help. He offered to ask the subject matter expert if he would be willing to talk to me. That was this morning, still no response so I'm beginning to feel hurt cuz he doesn't want to talk to me... Oh well I guess I'll get over it. Bryan I noticed the typo right away so it didn't effect me, I just followed what you were saying and it helped. Rolf thanks for the explanation, I think it may have really helped. Especially with the NUTS source code. I'm a labview guy so it's not going to be easy but there is a bunch of information in there... I might be able to piece it together. Especially with your explanation. I sent ~00P003IDN and the response was ~00R I kind of expected some model number or something. I think lessons learned here are the protocol document Tripp-Lite is sending out is wrong. The commands I'm sending don't even come close to the format the protocol document states. Again, thanks to everyone who chimed in... I'm feeling optimistic I can get something accomplished here. Bob

No response from either...

Bryan, Not quite sure what you mean by duplicating the same command/response. I just noticed something in my first post might be a little misleading Although I did view this on the comm port for a write command 7E 30 30 50 30 30 34 53 4F 4C 31 This is what I sent on my labview code 7E30 3050 3030 3453 4F4C 31 When I send this from my labview code 7E30 3050 3030 3453 4F4C 31, I get back this 7E30 3044 3030 3130 from the UPS. Not sure if that's important or not...

Once again my lack of knowledge on Hex is byte(ing) me.... According to documentation this is the hex string I'm supposed to use to communicate with my UPS. Write 7E03 0218 009B Read (UPS should return) 7E05 0318 B004 52 The command should be parsed as follows in my write example Header (1 byte), 7E, Type (1 byte) 03 Polling Command, Length (1 byte) 02 # of bytes from Report ID to Data, Report ID (1 byte) 18 Inquire Input Voltage, Data (64 bytes max) 00 no data sent, Check Sum (1 byte) 9B Sum of bytes from Header to Data Overflow Ignored So that all seems to make sense to me, but I can't get it to work. So I gave up and ran their software and looked at what was crossing the comm port. This is what I saw Write 7E 30 30 50 30 30 34 53 4F 4C 31 Read 7E 30 30 44 30 30 31 30 I understand this is not the same Report ID as my example, it is more than likely Report ID 50 which would be PresentStatus What am I missing???? Thanks in advance... Bob

Shaun, The "sum the bytes from header to data" is stated. Thanks, Bob

hoovahh, Tried your software... It's for an different version UPS and the protocols are different. That said I just modified your software with the current protocol commands and I get the same results, read function times out. I'm leaning toward my problem is not software related, but hardware. Probably the USB to RS-232 converters I'm using. I just had a wild thought and tried to connect to the UPS using my USB to RS-232 converter and their PowerAlert software. Of course there are variables they ask you to select the communications protocol and the protocol they sent me (4001) isn't listed out of the probably 30 protocols in their dropdown. I selected a couple that sounded right but I can't connect with their software on this port either. Crossrulz, I'll ohm out the cables they sent to see if anything looks bad. Everyone, Thanks for looking and trying.. It's just really hard working from home without the proper resources to get the job done. Bob

Bryan, Ok... I've always said there are no stupid questions... It's protection for me when I ask that stupid question.... I looked on the back of the unit and there is only one DB9. You're right about the "dry contact" connections. They are confusing, but Tripp-Lite tech support assures me I can communicate serial on the DB9 connector. I agree, the manual, protocol documentation and tech support for purposes of software aren't very helpful. Bob

Crossrulz, The UPS model # is SU750RTXL2U. I have the programming protocol from Tripp-Lite and I would post it here but it clearly says at the bottom of every page "All technical information contained in the document is the exclusive property of Tripp-Lite and may neither be used nor disclosed without its prior written consent." That said the protocol document is very vague, in my opinion it leaves out some very important information. As to the string I'm sending (hex) 7E03 0218 009B. 7E is the header and will always be ~ or 7E, 03 is the type (01=Command Rejected (UPS -> Computer), 02=Command Accepted (UPS -> Computer), 03=Polling Command (Computer->UPS), 04 Set Command (Computer -> UPS), 05 Data Returned (UPS -> Computer). 02 is the length (number of bytes from Report ID to Data), 18 is the report ID (in this case 18 is inquire input voltage) 00 is the Data portion in this case no data, 9B is the check sum which is the sum of bytes from header to data. As to the string I would like to receive it should be 7E05 0318 B004 52 the data portion is B004 which should be 1200 or 120.0V OK, with all that said. I'm getting a timeout from the read function. I think this means either as you say I'm sending an invalid command, or the UPS isn't receiving the command string at all. Wish I could determine which it is. Still wondering about the USB to RS-232 converters I'm using. Thanks, Bob

Crossrulz, What do you mean by "Then you need to read using the protocol of the device" The read buffer is always empty. When I send this polling command the response from the UPS should be 7E05 0318 B004 52 the data being 1200 or 120.0V Thanks, Bob

Sorry sent wrong pic

Here is another snipit showing all the inputs and outputs. Although the Tripp-Lite documentation doesn't address termination characters, I've tried it with and without. I've used bytes at port and just asking for a large read, neither works All the VI's run without errors until the Read function which in this case it gives warning about Bytes read equals bytes requested... There may still be data on the bus. Without using the Bytes at port and asking for 50 to 1024 bytes the error is a timeout. The write return count is 6, read return count is 0 I appreciate your help... More then likely in the end I will have missed something stupid... Thanks again, Bob

I'm having difficulty communicating with a Tripp-Lite UPS via serial RS-232. One variable I need to rule out is the USB to RS-232 adapter cables I'm using. I seem to remember there being some chip sets that didn't work well so I thought I'd ask the group. I've tried two different cables. The SABRENT Model CB-FTDI using the FTDI chipset and the UGreen using the Prolific PL2303 chipset. Does anyone have any experience with these cables? Any cables/chipsets you have used before without problems? I'm heading down this path because when I send a command that should ask the unit what the input voltage is I don't get any response at all from the UPS. In fact it doesn't matter what command I send, I get the same results. The config vi runs with no error, Open and write also run without errors, when I use bytes at port it returns 0, above I just ask for 1024 but the results are always the same, the read function times out with an empty read buffer. I think next week I'll go into the lab and try using the PXI-8430 and a straight through serial cable. I just really think this should be working... Does anyone see anything I'm missing? Thanks, Bob

Sorry...

Yes you are right, using the RS232 com port does not utilize HID Protocol. On these UPS's if you want to use the USB port it uses HID protocol. Don't fully understand why they would make it different on the USB port. I also agree using the RS232 port should be easy... But it's not. And that may be my fault. Working from home I don't have all the accessories I have at work. For instance since I can't communicate at all, I don't know where the fault lies. Is it my formatting of the string I'm sending, is it the USB to RS232 converter, is it something I'm not even thinking about??? My next step is to go into work and use a PXI-8430 to eliminate the USB cables. Just straight serial cable to the UPS. If that doesn't work I'll really be lost. I didn't state in my previous post when I write to the port it always returns 0 bytes at port and the read function times out. Any thoughts would be appreciated... Thanks, Bob

very vague. I was going to enclose it, then I read I can't. This pretty much covers configuration: RS232 Configuration: Baud: 2400 Data: 8 bits Parity: None Start Bit: 1 This pretty much covers message format: Message Format(Binary): Header Type Length Report ID Data Check Sum, Header 1byte, Type 1 byte, Length 1 byte, report ID 1 byte, Data 64 bytes max, Check Sum 1 byte. As I understand it the header is always ~, (7E) the type is 03 (Polling command), the length is 02 (the number of bytes from report ID to data), Report ID 18 (inquire input voltage) no data so 00 and check sum is 9B (sum the bytes from header to data) When I send (hex) 7E03 0218 009B it gets through write, but bytes returned is always 0 and read buffer is always empty. It would seem to me the UPS is not understanding the command or it's not really being written to the UPS. I'm working from home on a laptop, so I'm using a USB to RS232 cable, I've tried two versions one from SABRENT and one from UGreen neither seems to work. Tripp-Lite told me I didn't need a null modem. So I appreciate that. Honestly I just noticed Message Format(Binary) so I attempted to send the request for input voltage (hex) 7E03 0218 009B as binary but that didn't work either. As of now I'm uncertain do I have a problem with the USB to RS232 cables, the formatting of the command, or just something stupid I'm missing. I would bet in the last one, I'm missing something stupid. Tripp-Lite refuses to get involved in any way with programming issues... Of course.... Thanks, Bob

HID already tested my sanity... Sadly I failed... Yes we looked at the relay card. I just want to get more UPS health information. These units are intended to run for years and it would be good if the user could visually see the UPS is working well. Also as I understand it they either short or open two pins in the DB9 RS232 connector when the supply power shuts down. Again, just looking for more... As usual....

Thank you all for the awesome information... It is truly appreciated... As hooovahh indicates it is to monitor the UPS health/status and know when the supply power drops out. If the power drops out, I need to safely shutdown several units before the UPS runs out of power. As Rolf indicates it is possible to do on the USB HID port but a real pita... These units will be in distant locations and I don't want any extra complexity or reasons for it to fail. hooovahh ended up using the DB9, RS232 port and that is the direction I intend to head. Again, thank you all for the information... You guys are always a huge help.

thanks again