Jump to content

Bryan

Members
  • Content Count

    268
  • Joined

  • Last visited

  • Days Won

    6

Bryan last won the day on August 20

Bryan had the most liked content!

Community Reputation

15

About Bryan

  • Rank
    Extremely Active

Profile Information

  • Gender
    Male
  • Location
    Central Pennsylvania
  • Interests
    Stuff and things.

LabVIEW Information

  • Version
    LabVIEW 2018
  • Since
    1999

Recent Profile Visitors

2,536 profile views
  1. I just found out this morning that "Runstate.Execution.TSDatabaseLoggingDatalink{GUID}" isn't a valid location for TestStand 2010 (and not sure what other versions). For 2010 at least, it is "Runstate.Execution.TSDatabaseLoggingDatalink{Database Schema Name}". After a lot of futzing around yesterday, I simply added a statement expression step after "Log to Database" in the "Log to Database" callback sequence. Note: I didn't want to create a new local variable in the sequences of each tester, so I used Step.Result.Status to temporarily hold my value (Probably not a good practice, haha):
  2. I figured I would post a resolution to my own problem for anyone who may run into the same thing. While searching for something unrelated today, I stumbled across my answer. TestStand creates a connection to the configured database with the first UUT that is tested and maintains that connection while UUTs are continuously tested. Only when the sequence is stopped is when the database connection is released. I was able to come up with my solution by essentially compiling what I found in my searches. In my situation - "hiccups" in network connectivity or with the SQL server cause t
  3. TestStand Version(s) Used: 2010 thru 2016 Windows (7 & 10) Database: MS SQL Server (v?) Note: The database connection I'm referring to is what's configured in "Configure > Result Processing", (or equivalent location in older versions). Based on some issues we've been having with nearly all of our TestStand-based production testers, I'm assuming that TestStand opens the configured database connection when the sequence is run, and maintains that same connection for all subsequent UUTs tested until the sequence is stopped/terminated/aborted. However, I'm not sure of this and
  4. I use "Synkron" and "Create Synchronicity" for daily backups of my laptop to a USB HD. Edit: They're both free.
  5. Well to be fair, some companies have done the same thing to their employees who have never claimed any experience with a particular item/software/etc.. I've worked a couple of places where it has been: "Oh, you double-clicked the icon for "X" application? You're now the resident EXPERT!". Not too long ago, we had a "Kaizen" event where we had moved a piece of equipment in a production cell. I knew nothing about said piece of equipment but it was Windows-Based, so I figured I would go ahead and reconnect the keyboard, mouse, monitor and power it up just to make sure that it still boote
  6. @pawhan11 That sounds exactly how SVN was set up where I currently work - Including having LabVIEW ISOs/Installers stored within. (I wonder if we work at the same company.) One of the drawbacks you've mentioned and I've found with SVN is the ability to search for directories/files/etc. There are tools out there I believe to do this, but, since I'm not an administrator, I can't implement anything myself. Something I've done is use the SVN commands to generate a text file listing of ALL of the SVN contents... then if I need to search for something, I use Notepad or Notepad++ to search for
  7. Our logging routines are home grown. Of course, we're not logging EVERYTHING, mostly just overall test results and not each bit of data collected from a UUT. Our older testers log production pass/fail data to CSV files (older testers) or the company's MS SQL database. I've wanted to use SQLite for local logging, but the push back that I got was that it adds a dependency - having to create or install a viewer to access the logged data. Most of the other Engineers that would be accessing that data want something that's ASCII based and easy to read and import into other formats that wou
  8. I haven't used many VCS systems aside from the very few variants that have existed at my current and previous employers where I had access for LabVIEW development. Since some of those places didn't view LabVIEW as a programming language, I wasn't often granted permissions to have access to their VCS systems. So, my experience is limited. I spent a lot of time in Visual Source Save, but that's not going to help you here. However, I was able to grasp SVN + TortoiseSVN pretty quickly. I've also (for a very short period of time) had a little experience with Trac, though not enough to be a
  9. Bryan

    NI PCIe-5140s

    I was able to find a Declaration of Conformity dated some time in 2011, and that it's a 12-bit digitizer via a Google search, so it shouldn't be that old. You may have to get into contact with NI to find out more on this card. Unless the card was such a flop for NI that they chose to erase all evidence of it's existence - never to be spoken of again.
  10. The Internet is loaded with examples of file sharing, so I don't really want to reinvent the wheel by writing up a tutorial. A Google search will yield tons of tutorials and examples and you can even search based on your computers' operating systems. For W10, Microsoft has the following article: https://support.microsoft.com/en-us/help/4092694/windows-10-file-sharing-over-a-network
  11. Are you meaning a *.txt file generated from a LabVIEW program saved onto a remote PC? You should be able to set up a shared folder with appropriate permissions on your remote PC and have LabVIEW save the file to the share. I won't get into the details since there's gobs of info on the internet on how to set up shares. Once it's set up, you can just have your LabVIEW program point to the path of the shared folder. For example: If your remote PC name is "REMOTEHOST", you name the shared directory as "LabVIEWDATA", and your text file name is going to be "TestData.txt", the file path for
  12. I'm not sure that you're going to be able to (easily) do what you want to do without some advanced programming to automate/manipulate Microsoft Excel (for instance, using ActiveX or dotNET), even then - I'm not sure it's possible to do what you're trying to do as it involves Microshaft software, over which LabVIEW will have limited ability to control. I agree with 'crossrulz'. Whomever is pushing this requirement may need to reevaluate the need for this functionality.
  13. There is a "Flush File" function in the "File I/O >> Adv File Funcs" menu that you can have execute after every write. However, If you already have Excel open to view the CSV file, I don't believe that Excel will automatically update your spreadsheet contents every time the file changes if that is what you're trying to do. I haven't tried that myself. If the above doesn't work, it may be that Excel doesn't constantly monitor the file and automatically update. You could try using the "Refresh All" button in Excel under the "Data" menu, but you'd have to do this manually. Ad
  14. We all know that they wouldn't be the first company to do that and certainly not the last. It's happened in places I worked before where we were forced to use some obscure, and non-user friendly software applications that were not the industry norm for reasons unknown. If I were to speculate, it was because someone in the upper echelon had been dazzled or were/knew someone who could financially gain by way of it. These applications were, as was said, enterprise level agreements/suites/etc. and likely cost the company a lot of money both in purchasing/agreements as well as the time wasted fo
  15. 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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.