Jump to content
News about the LabVIEW Wiki! Read more... ×


  • Content Count

  • Joined

  • Last visited

  • Days Won


ensegre last won the day on November 9

ensegre had the most liked content!

Community Reputation



About ensegre

  • Rank
    Extremely Active

Profile Information

  • Gender
    Not Telling

LabVIEW Information

  • Version
    LabVIEW 2017
  • Since

Recent Profile Visitors

2,234 profile views
  1. ensegre

    How to delete phantom controls from a TypeDef

    Another thought - where is the black ear on the cluster icon? I mean, are you sure that this cluster on the BD is really the one you typedef'd? And if it is, and if I look at your FP image, which controls are flag_Z and flag_E? Are "Auto zero-enabled" and "same kind" captions instead of labels?
  2. ensegre

    How to delete phantom controls from a TypeDef

    If you attach your .ctl, maybe someone could look into it. Anyway, have you tried to autosize to fit the cluster? My guess are that the extra controls are in there, just far out of your current border. Reorder controls in cluster might also give you some hint. Just open your typedef, create a new cluster (this will temporarily break the typedef), and drag into it the elements you want to keep. When you are done delete the original cluster and apply changes. That saves you from replacing every single instance of it in your codebase.
  3. Update just for the record - a number of phone calls to the representatives, "so explain me again what error do you get" "Did you read my email?? When do I get an updated firmware?" I got this new firmware, whose release note spells Fixed Problems -------------- - some improvements in Ethernet communication and the problem disappeared...
  4. ensegre

    smallest FP size

    Is anyone aware of a limitation on what the smallest possible FP size is? On LV 2017, I am under the impression that this is 116x41 on one windows machine, and 1x1 on a linux. Known issue, WM, or deserves a CAR? The reason I'm asking: I'm fiddling with the cosmetics of an Xcontrol. I would have nothing against a larger transparent border, but when I webpublish the big FP using it, the large transparent border turns grey on the snap png. ETA:, ah, https://forums.ni.com/t5/LabVIEW/How-to-set-front-panel-size-to-be-same-as-one-led/td-p/1565524 ETA2: ok, tried the snippet of that thread and get either no reduction or eloquent "Error 1 occurred at Property Node (arg 1) - Command requires GPIB Controller to be Controller-In-Charge" for tighter sizes.
  5. ensegre

    Read Holding registers of Radix x 72

    crosspost: https://forums.ni.com/t5/LabVIEW/Read-Holding-registers-of-Radix-x-72/td-p/3835439
  6. ensegre

    [CR] LabVIEW Task Manager (LVTM)

    An UI glitch, I realize. On the toolbar, the light bulbs icons are inverted. The left one turns highlighting on, the right one off. The tooltips are correct.
  7. ensegre

    LabVIEW on Intel NUC

    Maybe 8.5 not supported on a newer OS? I can only say I have LV17 running ok on an i7 7567U, Win 10 enterprise 2016 LTSB
  8. ensegre

    Ring Control: event for the current value?

    I tried Mouse up, and discovered that it works only if you choose the last element and move the pointer out of the popup window but still at the edge of the bevel. Curious to know too.
  9. I don't use this device, but: you mean what, you got a DLL exposing those functions, and you have a problem when calling this Ch.extendedSegmentedMotion() from labview? If so, are you able to call successfully any other function? If that is the case it may be a simple mistake in interfacing with the CLFN - calling convention, wrong typing of the arguments, or the like. What did you try and what are the results?
  10. Note taken. For the moment though I took the path of calling Pfeiffer service. It would make more sense to me that their firmware is buggy, failing to release a disconnected port. After all this device acts as a telnet server, when it refuses incoming connections I would blame it rather than the client. Oh, and no, today I had occurrences when neither windows nor linux could connect, as well as ones where disconnecting and reconnecting the cable a few times didn't lose it. Either I'm missing something in this tests, or something is fishy.
  11. [after some more inconclusive tests with another linux laptop back-to-back and intranet, and dumb wiresharking]. Maybe. I mean, you're not suggesting to disable Nagle (that would effect all other traffic from the host NIC, probably not good), just to get the handle from that VI. I'll have to educate myself, e.g. https://stackoverflow.com/questions/3757289/tcp-option-so-linger-zero-when-its-required. I wish I could defer it to a rainy day, unless hangups with that device become frequent. Oh, is this in the way?
  12. Still shamelessly hijacking. So I'm polishing this VI, using basic tcp/ip, and observe the following. I have occasional network disconnections, and work around then attempting to reconnect, if tcp read gave error. I'm testing it on various PCs, with the device connected back-to-back or through some amount of intranet. Disconnections are easily simulated by pulling the ethernet cable and reattaching. Now my consistent observation is: one linux machine, reconnection seems to work robustly well. Three windows machines, quite often re-open TCP fails with Error 56. Not even restarting labview helps, only power cycling the instrument does. [I haven't yet had the chance of trying when both win and linux are on the same intranet]. Any idea why this is happening, is windows basic tcp different? Can I force some kind of port release harder than with tcp close?
  13. yes, wireshark with plain telnet should be easy. I got the impression that I ended in a case of "device refuses to admit the connection broke, and refuses a new connection because outbuffer is full", whatever. If so, avoidable with programming by not asking too much at once. For the rest, I'm probably there, by now. Pfeiffer Maxigauge TPG 366, btw. Thx both for the feedback!
  14. Thanks for confirming, Rolf. I also suspect that in addition to that is that ::socket is a windows only concept, or perhaps I don't have a sane VISA on my linux dev. I'm actually progressing with plain TCP. I'm only stumbling in my device sometimes hanging and refusing connections, this was what confused me at the beginning. A matter of programming so to avoid the condition which causes the lock, rather than abruptly power cycle the device. Anyway, now seemingly related to the particular device and not to the communication layer.
  15. You mean plain tcp read/write VIs? I am wondering. Searching just a bit more I found that I can use VISA read/write with resource id TCPIP::<ip>::<port>::SOCKET; what I'm fighting with now is how my instrument behaves in term of holding a failed connection and refusing a new one. I need to disentangle a bit the message protocol itself and the odd behaviour around it.

Important Information

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