Bryan

We've been using these Scales by Sartorius. They were Denver Instruments scales incorporated into Sartorius. I don't recall the measurement resolutions, but I do know that they are extremely sensitive. They're USB devices detected by Windows as a Serial COM port device and we use serial commands to interface them (e.g. NI VISA). However, we have had some that stop responding to serial commands over time. Sartorius wasn't much help with the issue though. In the end we ended up taking one apart and rerouting a ribbon cable or otherwise messing with cables to get it to communicate more reliably. We do have another scale that we haven't been able to fix with that method that is just currently sitting on a shelf as it's warranty ran out and we just keep it for manual measurements.

@rharmon@sandia.gov I'm glad to hear that you're making progress! Hopefully TrippLite is able to help.

Yeah... that was my bad. Sorry about that.

I don't know if this explains what I'm trying to say better: ASCII: � 0 3 0 2 1 8 0 0 9 B HEX: 7F 30 33 30 32 31 38 30 30 39 42 OR ASCII: � 0 3 0 2 1 8 0 0 › HEX: 7F 30 33 30 32 31 38 30 30 9B

Okay, sorry... I thought maybe you were monitoring THEIR software command/response by some method. When I said "duplicating", I thought you hadn't tried it with your code yet, it sounds like you have. So you're communicating with the UPS now? Good! I'm still wondering though if it's expecting hex values that would represent the ASCII characters for the ...03 02 18 00... and possibly the "9B". I'd be interested to see if you get any responses for the following commands. They are what I was trying to explain above (though, probably not explained well... I'm not always good with the words putting together thing): 7F30 3330 3231 3830 3039 42 OR 7F30 3330 3231 3830 309B

I wonder if it's a mix of hex and ascii somehow based on what crossrulz said - like the 7F is supposed to be a hex byte (non-printable character), but the remaining values (including possibly the checksum) are to be the ASCII representations of the numbers... for instance: 7F 03 02 18 00 9B Could really be sent as: 7F 30 33 30 32 31 38 30 30 39 42 (Again, I'm not sure if the checksum would have to be ASCII or Hex... you could try it both ways. )

Have you tried duplicating the same command/response with your LabVIEW code? I'd be interested to know if you'd get the same result. If so, I agree with crossrulz - that something is up with the protocol.

Yeah, working from home can be a pain for those of us who require physical hardware in order to be effective at what we're doing. We're doing somewhat of a 'rotation' of Test Engineers where I work, so on my days in the building, I can grab things to take home if needed... but ya always forget something. Haha! It would be great if you had access to a physical DB9 Serial connection on a computer to try. I know that very few laptops come with them these days and we're forced to use those &%#@ adapters. I know that some of the pins used by the dry contacts are used for other things with normal serial communication, which is why I'm confused that Tripp Lite says it'll work with serial - unless you have to have a custom cable of some kind. Like I mentioned before though, I'd be tempted at this point to try using the USB connection on the UPS and install their driver. Windows may be able to see, and allow you to treat it as a serial device via that method. I hope you're able to figure out what's up. If I think of anything else that could be useful I'll be sure to post it. In the meantime, if you get it figured out, please keep us updated on what you found.

I just looked up the owner's manual for that UPS (https://www.tripplite.com/support/owners-manual/45875). If you look at Pg 6, it looks like there are 2 DB9 connectors on the back... is yours like this? (Stupid question: Are you plugged into the right one?). Also, on Pg 12, it mentions "dry contact" connections under USB and RS-232. It's kind of confusing, but it looks like it could possibly be using a mixture of contact closure and RS232 communications on one cable... this seems unusual (and I may be reading it wrong, I'm in a hurry), but if that's the case, connection of anything other than pins 2 and 3 to your computer could be causing issues. What concerns me is that pin 5 is normally used for communication ground, but the documentation looks like it says that the contact closures are using those pins as well as pin 3. I'm wondering if the DB9 connections aren't intended for serial communication. Some devices will show up when plugged in via USB as a Serial Device with a COM port assignment (may require a driver installation from them). Perhaps that's what they mean by serial/rs-232? If so, their documentation (that I've found anyway) isn't very helpful. I also just noticed that your baud rate in picture above is set to 2400, which isn't typically common on modern serial devices anymore. 9600 used to be the norm, but I've seen 19200 and 115200 commonly used on devices as well. I've never interfaced one of Tripp_Lite's UPSs before though.

You're right, either the UPS isn't GETTING the command, isn't UNDERSTANDING or is IGNORING the command or is responding and it's not making it back to the computer.

I work with those CURSED USB to RS232 adapters nearly every day and have had a whole range of different issues with them. I won't get into it all here, but here are the troubleshooting steps that I typically do in no particular order: 1. Jumper the Tx and Rx pins on the connector closest to your device to form a loop back (pins 2 and 3). 2. Use PuTTY or some other method to send data out, you should get the exact same data back. If you get data back, then you're communication is making it round-trip to at LEAST the connector of your device. 3. Try a null-modem cable/adapter, which swaps the Tx and Rx pins between one end of the cable to the other. Sometimes manufacturers don't make it easy to figure out if it's required. 4. Double-check to make sure your Baud rate, data bits, stop bits, parity and handshaking have been configured to match what the UPS is expecting. It looks like you're specifying a termination character for READ (For the initialization, 0x0A), but not enabling it. If the UPS requires a termination character, you'll have to explicitly send one with writes, it doesn't automatically append. If the UPS is expecting it, you may have to add an "0A" to the end of your hex string. 5. Look in the documentation to find out if the UPS requires any special termination characters, start/stop, etc characters - I.e. is what you're sending properly formatted? I've had devices which required unusual starting and termination characters before, with or without the common "0x0A termination character. 6. Your VISA Open timeout is zero, try adding something a little longer... possibly 50ms to 250ms or so.

@Chris Cilino It's working for me now... It wasn't before. Sorry for the false alarm.

I had a TI-85 that I had to buy for college. Loved that thing. Lent it to a friend of mine where I used to work, who accidentally left it in a conference room and I never saw it again. They gave me their TI-83 as a replacement, but I had a lot of programs I wrote on my 85 that were lost.

Linky no worky for me...

It works for me just fine on latest versions of Chrome, Firefox and Edge. Stupid question: have you tried clearing cookies and cache? On a side-note:

Ditto! It's bitten me a couple of times since I started at my current employer. I've found instances where developers (who are no longer here, or were contracted by a certain NI Alliance Partner) have configured global tasks and channels in MAX and called them from LabVIEW/TestStand code. Also, I've seen where they've defined custom names for devices in MAX and referenced them in LabVIEW executables. I don't now what's been causing it lately (Win-blows updates?), but several of our factory testers, which use the methods above have been "forgetting" their custom MAX-defined names in recent weeks. Backups of the MAX config aren't always there, so I don't know what the names SHOULD be. I've had to try to find the source code for LabVIEW executables in several occasions in order to figure out what the MAX configuration should be, but have found that either the source code was "lost", or not all dependencies are there. I won't mention the name of the NI Alliance Partner that did some of the testers. It was actually a company that I was thinking of applying to when I was in danger of losing my job due to reductions in force, but I will say that if an operator tells me that there's a problem with a tester, and that it's a __________ tester, I always *sigh*.

Sorry to revive an old topic, but I'm currently looking for a solution to this as well. I had found something on the NI forums, but it looks like it only works for TestStand 4.1.1. : Runstate.Root.Locals.DatabaseOptions.ConnectionString However, I'm using TestStand 2013 and 2016 and this expression doesn't appear to be valid for these versions. Edit: After some digging, I found that it can be found at: RunState.Root.Locals.ModelPluginConfiguration.Plugins[ARRAY] This will return an array of configured plugins. I'm assuming that this is going to vary for everyone, but I was able to find mine at: RunState.Root.Locals.ModelPluginConfiguration.Plugins[1].PluginSpecific.Options.ConnectionString I'm far from a TestStand guru, but I'm sure that I can write something to parse and find the connection string as I'm assuming that the array position may change in the future. But I'm hoping that someone has a simpler, more robust method of getting the configured connection string.

You could add additional I/O to the Pi by connecting Arduinos to it. If you install LINX on the Arduino(s), your deployed LabVIEW application can control I/O on the Pi AND on the Arduino(s) using the LINX toolkit. I haven't done this personally (I'm using another home-grown method), so I don't have a "How To" for it. However, I know that I've stumbled on the above idea in one of my recent Google searches.

As an individual of alternative-handedness, I find this thread and its comparison to my suffering by the majority in a right-handed dominated world to be offensive. 😁 Nah... we lefties improvise, adapt, and overcome. <Insert meme featuring Bear Grylls here>

I'm attempting to get LabVIEW 2018 along with DAQmx and VISA installed on a machine (virtual) running Centos7 and am wondering if anyone else is doing similar. The main problems I've run into, by following NI's instructions for DAQmx and LabVIEW 2018 support is that it appears some of the DAQmx tools don't install (e.g. "lsdaq") and the additional NI software doesn't appear in the "Applications >> National Instruments" Gnome GUI menu. I can access serial devices once NI VISA is installed (after adding myself to the "dialout" group), but cannot see or access any DAQmx devices using their method in the link above. I have had some success using previous versions of DAQmx for Linux, but ran into issues and conflicts between modules used VISA and DAQmx. At any rate... I'm wondering if anyone has gotten something LV2018, VISA and DAQmx to work on Centos7 or RHEL7 yet... and if so, what issues/fixes/workarounds you had to do in order to get it to work.

What type of serial communication are you using? RS232, RS485, RS422, I2C, SPI, ETC? The type you are using will determine whether it's physically possible to have multiple masters/slaves on the same connection. If you're using a compatible serial connection, yes... LabVIEW can do what you're asking. As far as how... there are already lots of examples built into LabVIEW and on the internet.

Your request is too vague. Please provide more information as gb119 had stated, otherwise we won't be able (or willing) to help you. Your request reads like: "Hey, I want you to help me come up with a thing that does stuff for free by the end of the month. Okay? Bye-bye!" Otherwise, it seems like you're (vaguely) asking for either free labor or trying to get someone to complete a homework assignment for you.

Okay... I'll bite just because I'm curious. While I was reading your post on how you fixed it, I was thinking of all of the times that I've reviewed code and shook my head when I see that type of programming.

No Problem!