Jump to content


  • Posts

  • Joined

  • Last visited

Profile Information

  • Gender

LabVIEW Information

  • Version
    LabVIEW 2014
  • Since

Contact Methods

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

ShockHouse's Achievements


Newbie (1/14)

  • Week One Done Rare
  • One Month Later Rare
  • One Year In Rare

Recent Badges



  1. I was working with a PXI-8840 dual-core, so slightly different than OP's, but we were successful in replacing the RAM using off the shelf parts just this past week. The original 4GB stick it came with was this: https://www.crucial.com/memory/ddr3/ct51264bf160bj We just bought the exact same model*, with instead 8gb: https://www.crucial.com/memory/ddr3/ct102464bf160b There wasn't any issues installing it, or being recognized.
  2. I asked this on the NI forums, but no response, so I'm hoping the expertise here might point me in the right direction. I'm trying to make an application that allows a user to modify the screen size and still be able to control everything. Most of this is done by having a main vi that has subpanels that get filled up with vi's. All of this is built upon actor framework. I don't want any elements on the front panel of the vi's to change size. The only thing I want is for the position of the vi within the subpanel to change so that it is always centered. I've achieved this by taking the size of a Pane, and setting the origin to the center based on the rectangular area of all the controls. This part works great. I programmatically turn on the scroll bars if the vi won't fit in the subpanel so the user can still get to everything. (The attached CenterControls.vi is what's going on here, with the help of FP_PaneRectangeAroundControls.vi) The problem comes when a user uses the scrollbar on a subpanel. Since the inserted vi is centered, because of the origin change, I would hope the scroll bar would take that modified origin and change it. Instead it seems like whenever I use the scrollbar it takes the previous origin, instead of the one I set. By that I mean, If I change the width of the front panel, and then scroll vertically, the vi will jump to the center before the width was changed. The same happens if I change the height, and then scroll horizontally. This causes my vi's within subpanels to be thrown to where they previously were centered. You can see that behavior in the gif I attached. Anybody ever ran into this issue and know a way around it? I would like to be able to center my vi's in the subpanels, and then for scrolling to work based on the new origin. CenterControls.vi FP_PaneRectangleAroundControls.vi
  3. Sorry I should have specified above. The code you download already is initializing an array of the correct size (because it's based on how many bytes you want to read). All you have to do is remove the Byte Array to String that goes into the buffer. And just pass the initialized array straight in to the buffer. So if you take the parameters I posted above, and modify the code to look like below it will work.
  4. Your exactly right. I went into the call library function for the read and changed it to a byte array. It now returns the correct values each time. So if anyone uses this and comes across the issue above go into the call library function for the Read and change the buffer to reflect the picture below.
  5. Just curious if any of you ran across this issue during your time using the FTDI I2C libMPSSE.dll. I can successfully write to a chip all the time. I can read from a chip a lot of the time, but I run into an issue in one scenario. If I read 6 bytes of value it will return something like this: 0xC08610E07EC0. The problem comes when one of the bytes of data read is 0x00. For instance: If I was to read and wanted to get 0xC08600E07EC0 it would only return 0xC086. This is because that byte right after is 0x00. I know the entire data is being passed back on the SDA line because I checked with an oscilloscope. The problem is just that the buffer for the Call Library Function doesn't return the data. I'm wondering if you guys have seen this issue? If not I'll just start looking into their dll and see what is going on.
  6. If anyone else comes across this issue and does not have access to the cables to install the driver (yet) I found a solution. The issue is the .dll call to libMPSSE.dll (which then tries to access ftd2xx.dll). There are two options to solve this that have worked for me. A: Although you can't open the individual .vi's, you can open the .lvlib and .lvproj. Open up the .lvllib and delete the libMPSSE.dll that is listed. (Also delete it from the Folder in your OS, save it to a different folder for the time being), This should allow you to open up the .vi's because they can no longer find the .dll so they will not crash. Now you can look at the .vi's for the time being. B: Another way is to just add the file ftd2xxx.dll to either your SysWOW64 folder or System32 folder (in C:\Windows). Since libMPSSE.dll looks for ftd2xxx.dll it will now find it. C: Wait for the cable to arrive.
  • Create New...

Important Information

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