Jump to content

JKSH

Members
  • Posts

    494
  • Joined

  • Last visited

  • Days Won

    36

Everything posted by JKSH

  1. That is the nature of memory corruption: Often, it doesn't cause a crash immediately. The crash happens later, when something else tries to use the corrupted memory. This is monitoring memory allocation. It helps you detect memory leaks, but doesn't detect memory corruption. They are different issues. Memory leaks cause crashes by using up all of your application's memory. Memory corruptions cause crashes by scrambling your application data.
  2. To be fair, I think DCAF is quite well-described at http://www.ni.com/white-paper/54370/en/ and http://sine.ni.com/nips/cds/view/p/lang/en/nid/213988 (Image from http://sine.ni.com/nips/cds/view/p/lang/en/nid/213988) The configuration aspect just one part of DCAF, and CVT fits inside the another part: The "Data Exchange". So, I'd say that DCAF can contain CVT functionality, but CVT doesn't do most of what DCAF can do.
  3. That's correct. That also means it is an issue for me, as I have 2 screens with different scalings.
  4. To solve both issues, insert "Adapt to Type.vi" before "Variant to Data". However, your cluster element names are now case-sensitive. "TimeStamp" will not match "timeStamp" in the JSON string.
  5. If you're considering this, then the next question is: What style of comments? @silmaril suggested YAML, which uses "# ...". JavaScript (which is where JSON came from) uses "/* ... */" and "// ..." Will you choose one to support? Will you support both (and any other style that might appear in the future)?
  6. Please understand: All of this is a lot of work! It can take several days of full-time work to finish. It is not reasonable to expect people on this forum to do your work for free. Someone needs to read through the data sheets. They might need to reverse-engineer the Cyton G15 shield hardware and/or code. Then, they need to make wires between the myRIO and the GD02, and make wires between the GD02 and the servo. They also need to write software for the myRIO to communicate with the GD02. Finally, they need to test everything. You should either hire someone to teach you how to do all of this, or hire someone to do it for you.
  7. I agree completely: Keep the Git-tracked config files separate from the deployment config files. Trying to make Git track the files and ignore the files at the same time is messy and unintuitive; if any errors occur in the process, they might be hard to detect and to fix. Some other possibilities to consider (these ideas aren't mutually exclusive; you can implement more than 1): Have your application search for config files in a "deployment" folder first. If those aren't found, then fall back to the simulation config files. This way, both deployment and development machines can run the same code yet read from different folders. This way, the "deployment" folders are untracked by Git and there's no risk of overwriting their contents. Make it visually obvious when your application is running in simulation mode (e.g. change the background colour and show a label). Deploy by building and distributing executables instead of pulling source code. It sounds like your deployment machines run the LabVIEW source code directly. How do you manage the risk of the code getting accidentally (or maliciously) modified by an operator?
  8. Not directly. One possible workaround: You could keep the .ctl as a Type Def most of the time. When you want to propagate cosmetic changes during development, temporarily Save + Apply it as a Strict Type Def. After that, change it back to a Type Def.
  9. You can use a basic state machine instead of a JKI State Machine: http://www.ni.com/tutorial/7595/en/
  10. I got an email saying that the next version of NXG is out... but nothing about 2017 SP1!
  11. (1) sounds fine. (2) could work, with caveats. You need to make sure that the data passed between LabVIEW and the 2 DLLs don't get destroyed too early. You also need to ensure that the 3rd party DLL is happy to be called from different threads, OR you make sure you only call it from the UI thread. No, I don't think your callback function can be "deallocated", unless you tell LabVIEW to unload your DLL. It has a permanent address in your DLL, after all. What kind(s) of data is transferred between the DLLs and LabVIEW? How are you ensuring that things are thread-safe?
  12. You're welcome, Fred. I see on forums.ni.com that your code is a bit different. In particular, your Signal array has 512 elements instead of 513. Which is it? You need to count accurately, or else your program might crash. Also, nathand posted more important points at forums.ni.com: You must configure the the Array to Cluster node correctly Each Array to Cluster node can only handle up to 256 elements. So, you need to duplicate its output to reach 512/513 elements.
  13. Hi, Your issue is related to data structure alignment and padding. See https://stackoverflow.com/questions/119123/why-isnt-sizeof-for-a-struct-equal-to-the-sum-of-sizeof-of-each-member By default, C/C++ compilers add padding to structs to improve memory alignment. However, LabVIEW does not add padding to clusters. So, in your DLL, the structs' memory layout is probably like this: struct Signal { uint32 nStartBit; // 4 bytes uint32 nLen; // 4 bytes double nFactor; // 8 bytes double nOffset; // 8 bytes double nMin; // 8 bytes double nMax; // 8 bytes double nValue; // 8 bytes uint64 nRawValue; // 8 bytes bool is_signed; // 1 byte char unit[11]; // 11 bytes char strName[66]; // 66 bytes char strComment[201]; // 201 bytes // 1 byte (PADDING) }; // TOTAL: 336 bytes struct Message { uint32 nSignalCount; // 4 bytes uint32 nID; // 4 bytes uint8 nExtend; // 1 byte // 3 bytes (PADDING) uint32 nSize; // 4 bytes Signal vSignals[513]; // 172368 bytes (=513*336 bytes) char strName[66]; // 66 bytes char strComment[201]; // 201 bytes // 5 bytes (PADDING) }; // TOTAL: 172656 bytes There are two ways you can make your structs and clusters compatible: If you control the DLL source code and you can compile the DLL yourself, then you can update your code to pack the structs. If your compiler is Visual Studio, add #pragma pack(): https://msdn.microsoft.com/en-us/library/2e70t5y1.aspx If your compiler is MinGW, add __attribute__((__packed__)): https://stackoverflow.com/a/4306269/1144539 If you cannot compile the DLL yourself or if you don't want to change the DLL, then you can add padding to your LabVIEW clusters. Signal: Add 1 byte (U8) to the end of the cluster Message: Add 3 bytes in between nExtend and nSize. Add 5 bytes to the end of the cluster. I must say, the Message struct is huge! (>170 KiB)
  14. I don't have a fix for the leak (and I haven't investigated it in detail), but I have an alternative architecture for auto-connecting comms. Instead of opening/closing in one loop and passing the variable reference to another loop, is it feasible to keep everything in one loop using a state machine? The states could be: Offline (the only state that's allowed to quit the loop) Connecting (contains the Open Variable node) Online (contains the Read Variable node) Disconnecting (contains the Close Variable node) Button clicks, panel close events, and read errors can be used to trigger state transitions.
  15. I don't have knowledge on this topic, but I'd imagine that you can delete the existing control and add a new one. This should give you a "factory-new" control which has no custom symbols.
  16. Interesting. I can't think of a reason why the DLL's missing (or why reinstalling doesn't bring it back), but you're welcome and I'm glad to hear you've found a solution! I don't think this forum supports the "mark as solution" feature. It caught my attention because currently, Office 365 installs Excel 2016, Access 2016, etc. by default. I thought that perhaps reinstalling Office 365 didn't help you because your copy of Access 2013 was installed separately from Office 365.
  17. So a "good" installation of LabVIEW's DB toolkit and/or Office 365 are happy with your query. This suggests that something is different about this installation... but uninstalling/reinstalling hasn't repaired it so far. I'm curious: You mentioned Office 365 and Access 2013. The current default version for Office 365 is Office 2016. Did you deliberately install Office 2013 via Office 365 (which requires jumping through some hoops, IIRC)? Or did you install the non-subscription version of Office 2013 separately from Office 365? Anyway, one more thing you can try is to compare DLL versions. When the exception pop-up dialog appears, use ListDLLs or Process Explorer to see which DLLs are loaded (full paths and version numbers). Do the same on your "good" installation, and see if you can spot a difference.
  18. They give the same error code, but what about the detailed error message? With your original query, the toolkit complained that it wasn't happy "in query expression '[UserID]'". What did it complain about in the other queries? I do agree with you that your syntax is valid. I was hoping that trying different syntaxes and studying the toolkit's response will yield some insight into why the toolkit is tripping up. Even though the query functions fine in Access 2013, we don't know that the Database Connectivity Toolkit passed your query as-is to Access 2013.
  19. Error -2147217900 is an SQL syntax error: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P83sSAC Also, your error message points out that the engine doesn't like the expression '[UserID]'. What happens if you try the following queries? What error does each query give (if any)?: SELECT UserID FROM [Operator]; SELECT UserID FROM Operator; SELECT * FROM [Operator]; SELECT * FROM Operator;
  20. I just logged in, and I'm able to browse forums threads just fine. Windows 10 version 1703 x64, with Microsoft Edge 40.15063.674.0
  21. When you break down your string into different sub-sections, the problem becomes much easier to solve. Don't try to handle 4 delimiters at the same time. The format for the full packet is: !<VOLTAGE_LIST>:<TIMER_LIST><CR> The format for <VOLTAGE_LIST> is: <VOLTAGE_PAIR[0]>;<VOLTAGE_PAIR[1]>;...;<VOLTAGE_PAIR[n-1]> The format for <VOLTAGE_PAIR[k]> is: <VOLTAGE1[k]>,<VOLTAGE2[k]> The format for <TIMER_LIST> is: <TIMER4>,<TIMER5> Notice that: The full packet only has '!' at the start, ':' somewhere in the middle, and '\r' (<CR>) at the end <VOLTAGE_LIST> only has 1 delimiter: ';' <VOLTAGE_PAIR[k]> only has 1 delimiter: ',' <TIMER_LIST> only has 1 delimiter: ',' You can translate the above breakdown into very simple LabVIEW code: Notes: The pink VI is <vi.lib>\AdvancedString\Split String.vi To make it appear in your palette or Quick Drop, install Hidden Gems in vi.lib from VIPM or http://sine.ni.com/nips/cds/view/p/lang/en/nid/212430 Alternatively, you can use OpenG's String to 1D Array.vi Regular Expressions (Regex) are very useful for string manipulations. Play with it at https://regexr.com/ (note: You might need to replace '\r' with '\n')
  22. That looks nice! It makes the safety logic easier to implement and understand. It's nothing like the LabVIEW State Chart Module, however: "With state diagrams featuring up to eight individual state machines per module, you can complete your programming. You can use AND, OR, and NOT logic along with programmable timers to determine when to transfer between the various states. In addition, you can assign up to 24 Boolean variables. After you download the safety logic onto the module, you can monitor AI, DI, DO, variables, and diagnostics in the LabVIEW Real-Time Module." There are no VIs involved at all.
  23. We used it in a few projects, but the biggest one which had lots of state charts became really slow to deploy. This made our workflow quite inefficient, as each time we wanted to update and test some code on a cRIO we'd need to spend ages waiting for the state charts to deploy (even if we haven't changed anything in the state charts or their VIs). The module's implementation doesn't scale well. From what I've seen, the State Chart module isn't that popular in Current-Gen LabVIEW. I think it's unlikely the module will migrate to NXG, not without being re-designed from scratch.
  24. JKSH

    SubPanel

    When you say "LV stops", I'm guessing you mean you stop your VI and return to Edit mode? Note that LabVIEW itself doesn't stop. Anyway, are you talking about cleanly shutting down your VI, or aborting it? If clean shutdown: Does it help if you make your framework explicitly un-insert subpanels during shutdown? If abort: I'd guess it's a reference that wasn't released properly. I haven't seen this, but it looks like a bug. As @Aristos Queue said in https://lavag.org/topic/20315-xnodes-prevent-inlining/#comment-123550 -- "Only squeaky wheels get grease", so do submit a reproducible example to NI if you can!
×
×
  • Create New...

Important Information

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