Jump to content

JKSH

Members
  • Posts

    442
  • Joined

  • Last visited

  • Days Won

    30

JKSH last won the day on June 6

JKSH had the most liked content!

1 Follower

Profile Information

  • Gender
    Not Telling
  • Location
    Western Australia

LabVIEW Information

  • Version
    LabVIEW 2020
  • Since
    2011

Recent Profile Visitors

7,411 profile views

JKSH's Achievements

  1. What's the context? Traditionally, I've treated good desktop app design as different from good industrial HMI design as different from good web app design, etc. But, contemporary designers are moving towards a unified approach. What are your thoughts on Google's Material Design, Microsoft's Fluent Design, or Apple's Human Interface Guidelines? https://material.io/design https://www.microsoft.com/design/fluent/ https://developer.apple.com/design/
  2. Can you say, "Here is the STOP button! The big red 'X' in the top-right corner of the window"? 😁
  3. Missing as in "field does not exist in the object", or missing as in "field exists but the value is an empty string"? The latter is not truly missing. It exists, and its value is an empty string. The former can be handled using the "Data Type and Default Value" inputs Sounds like you're using "Find Item.vim"? Make use of the "Found" output, OR switch to "Find Item (as LVtype).vim" to specify the default value. How do you envision providing the default value if you are able to filter out the proposed "Empty String" error?
  4. The current pink wire datatype needs to remain as a "byte string" plus "locally encoded text string" to maintain backwards compatibility. A new type of wire (Purple? Darker than pink, paler than DAQmx wires?) should be introduced as a "universal text string" datatype. Explicit conversion (with user-selectable encoding) should be done to change pink wires to purple wires and vice-versa. Binary nodes like "TCP Read"/"TCP Write" should only use pink wires. Purple wires not accepted. Text nodes like "Read from Text File"/"Write to Text File" should ideally only use purple wires, but they need to allow pink wires too for backwards compatibility. VI Analyzer should flag the use of pink wires with these nodes. Perhaps a project-wide setting could be introduced to disable the use of pink wires for text nodes.
  5. How about wiring the string into a case structure selector? Case "": Do your special output Case Default: Wire the string into the JSON VIM
  6. If you only need to read the basic standard messages defined in J1939, then you can can treat the frames like any regular CAN frame. You just need to map the frame IDs to J1939 PGNs (for example, CAN frame ID 0x0CF00401 is for "Electronic Engine Controller 1" and bytes 4-5 contain the "Engine Speed" value) However, if you need to do do complex things like read multi-frame data or send a command and read the response, then you need to write a lot more custom code. Fortunately, NI has provided an example that covers a big chunk of what you need with the NI-9853: https://forums.ni.com/t5/Example-Code/J1939-Transport-Protocol-Reference-Example/ta-p/3984291 (use the non-XNET code) On the bright side, since you're doing FPGA programming, it doesn't matter if the CAN module is on an Ethernet expansion chassis or if it's plugged directly to your controller -- your code would be the same either way AFAIK, that only provides mapping for the basic messages that fit within a single frame, and some basic standard hanshaking + diagnostics. NI-XNET has no built-in support for multi-packet data or complex comms. I used the XNET example from https://forums.ni.com/t5/Example-Code/J1939-Transport-Protocol-Reference-Example/ta-p/3984291 as a starting point, but still had to write a lot of custom code to encode/decode messages and handle command-response handshakes.
  7. @Rolf Kalbermatter has the answer, as usual: The parameter type is a pointer-to-InstanceDataPtr (i.e. a pointer-to-a-pointer, or a Handle in LabVIEW terms). LabVIEW owns the handle, you own the data pointer: You allocate the data in Reserve and you can access that same data in Unreserve/Abort. LabVIEW can't free your pointer since it doesn't know the type/size of your data. // C++ example #include <ctime> MgErr reserveCallback(InstanceDataPtr* instanceState) { if (*instanceState == nullptr) { time_t* start = new time_t; *start = time(nullptr); *instanceState = start; } else { // We should never reach this point, unless the InstanceDataPtr was not cleared after the last run } return 0; } MgErr unreserveCallback(InstanceDataPtr* instanceState) { time_t end = time(nullptr); time_t* start = static_cast<time_t*>(*instanceState); // Calculate how much time has passed between reserving and unreserving double elapsedSecs = difftime(end, *start); // Note: The handle must be explicitly cleared, otherwise the LabVIEW IDE will pass the old pointer // to reserveCallback() when the VI is re-run delete start; *instanceState = nullptr; return 0; }
  8. It's a pretty common spam technique, designed to sneak spam links into innocent-sounding posts. A moderator should clean out the spam.
  9. JKSH

    Slow MD5

    That means it is using OpenSSL 1.0.x or earlier. In OpenSSL 1.1.0, "libeay32" was renamed to "libcrypto"
  10. Or even better: Replace "Write To Text file"/"Read From Text File" with "Write To Binary File"/"Read From Binary File". The output of "Flatten to String" is not text. (String != Text)
  11. If it's a new-ish installation, the uninstall utility is replaced by NIPM. But that does also provide a comprehensive list of installed NI software.
  12. I don't have one for sale, but our customers would like to purchase cRIO 904x too. Unfortunately, current lead times from NI are around 12 weeks.
  13. Ouch. Can you please wave this in NI's face? https://forums.ni.com/t5/LabVIEW-2021-Public-Beta/bd-p/labview-2021-beta
  14. For those who don't want to watch the video, the list of improvements is also published in the Public Beta: https://forums.ni.com/t5/LabVIEW-2021-Public-Beta/LabVIEW-2021-Beta-Now-Available/td-p/4144143 I don't think that's a bad thing. NI can't exist as a silo and still hope to be relevant to the rest of the world. Better interoperability makes it easier to justify using LabVIEW in a multi-technology environment (which is often the case in large organizations), and makes it easier for scientists and engineers to start using LabVIEW. Yeah, those are a bit vague. The second half of the list sounds like the porting over of features from NXG, which seems like a sensible direction (consolidate existing features before coming up with new ones)
  15. Hi @LVmigrant, and welcome! I think nothing beats the effectiveness of a well-designed and well-delivered training course -- you'd learn the most from them in the shortest amount of time and you can be taught to avoid bad habits that might be found online. Still, forums are definitely a helpful way to learn. I studied electrical engineering and basically developed most of my software-related skills via forums, StackOverflow, and lots of home practice. After that, I got my full-time job as a LabVIEW-based programmer in a systems integration company.
×
×
  • Create New...

Important Information

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