Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by shoneill

  1. Actually no, seems unreachable again.
  2. yeah, but banned again..... I don't know how to configure Firefox to limit the connections and Filezilla doesn't want to work... complains about invalid directory listing. I just download 4 files a day..... yawn.
  3. Yes, thought it was just me. Also 323_Casey Lamers_Understanding Decoupling of Messaging in Actor Framework.mp4 crashes at 39.02.
  4. VI window title says "Exercise" so you need to finish the code yourself.... it's not supposed to be a working VI until you actually do some work. It's to help you learn.
  5. I'm pretty sure that's a good indicator, but not foolproof. I've had LabVIEW "idling" for nearly an hour, frozen, and come "back from the dead" afterwards. I've also had LabVIEW be "active" and not recover even after leaving it carry on for a whole weekend. Maybe if I had let is continue for just 5 minutes more, it would have completed...... I've grown to expect all kinds of weird behaviour from LV over the years. That's not meant as a compliment. I suppose we need considerably more feedback regarding what LabVIEW is actually doing so that we can better judge whether stopping the process or just waiting is the best option.
  6. Does LV freeze or crash? I often see "freezes" of more than one hour when LV starts compiling our entire project when just moving the files to a new path on disk. If I wait long enough, it does eventually recover, but at that point it's hard to differentiate between this and "normal" LV crashes where it just sits there and does nothing and will never recover. I say "normal" because it happens quite a lot. LV 2015 SP1.
  7. Every time I try to download videos my IP gets banned..... Only got 8 of them before lights out....
  8. Ah yes, I remember this now, I "abused" this when doing some USB programming of my own to install LibUSB drivers for a given device on one port, and standard NI-USB drivers on another port for testing. In order to change driver, all I had to do was switch USB port instead of constantly uninstalling and re-installing. It was a nice trick (in XP at the time), I don't know if it still works with Windows 10.
  9. No problem, no hostility detected. Honestly. Also none implied at all. I just noticed that the focus of my answer wasn't explained properly. Your "oops" while acknowledged, is not neccessary at all. Nothing whatsoever to apologise for. Although I knew my post was only focussing on the "multiple devices" issue, I simply didn't convey that properly. My bad. I only realised it after your post.
  10. My post seeks only to explain why the renaming takes place. If there's a rapid power off and on, not supporting a proper Serial Number can lead Windows to whink a new camera has been attached. I think the base problem you have is a power supply issue, and there USB is flaky at best. The issues you see with MAX are understandable from an unstable power point of view. Sorry that I didn't portray that information more clearly. Filtering of power over USB is nororiously crappy for most motherboards, for possible fixes, Bobillier's suggestions above soumd perfectly reasonable.
  11. If a USB device does not implement a Device Serial Number correctly, Windows cannot distinguish between a second instance of the same camera being attached and the reconnection of the same camera. This leads to numerous "instances" of devices being installed in the system. If done correctly, the OS should be able to assign a driver to an instance of a specific device (taking serial number into account). The serial number of a device is normally defined in the device configuration package which an OS needs to read before it can even assign a device class. A lot of devices simply don't implement this. Also see HERE for info on where this data SHOULD be stored.
  12. There is no new dynamic refnum behaviour. It behaves just like it was always designed to behave. The left and right sides of the terminal in the event structure have always worked that way.
  13. All of my input has been technical. The information you seek is all in this thread if you care to find it. I also never used the word "misrepresent", so I'm unaware what you're referring to here. Is this supposed to be a joke regarding misinterpreting my misinterpret? I disagree re. the plea to authority. Plus, I'm fully aware of the ridculousness of the logical extension of what Linus said when context is ignored. Note the smiley. Well, for yourself perhaps but others read these threads also so even if you stoicly refuse to listen to any relevant technical details (or god forbid, other opinions), others may be able to incorporate the technical details of the discussion to help form their own opinions.
  14. I never claimed you said that. But it was said. The code I posted illustrates why the proposed operation is incorrect. Jack's code only serves to illustrate why your intuiting which led to your original code was flawed. I don't think I've misinterpreted anything. I understand the original code, the changes and the workarounds. The workaround is to better understand the issue and code appropriately. Regarding not wanting code to change and the plea to Linus' authority: Taken at face value, Linus' comment would preclude the closing of any security flaw which has ever been exploited. Yes, obviously Linus is claiming that Spectre and such should be maintained indefinitely as some may be using it.
  15. The code I posted illustrates why a "read only on first call" cannot work. If what you said is not rubbish, then more clarification is needed because by my understanding it is. You can change the protoype refnum for another of the same type no problem. You can bait and switch to your heart's content. Hence my insistance on differentiating between the data contained within the Refnum and the Type fo the refnum. One is possible to switch (without invalidating anything), the other isn't. Of course you can't change it for a refnum of a DIFFERENT type, that's a design time decision. The code I posted swaps out the refnum for another, but of the same datatype and therefore there's no invalidation at all.
  16. And this relates to your original code....... how? You are NOT changing the datatype of your registration refnum, you are changing the data on the wire (which is the first of the two cases I mentioned in my previous post) and for which I posted a trivial example.
  17. The usage of the word "Prototype" was careless. Use "Datatype" instead. If you mean changing the data carried on the strictly-typed wire attached to the left-hand side of the event structure, then the job queue for the event structure changes to whetever is contained there. As expected really. Jack Dunaway has an example of it in a link previously provided (not by me) in this thread (snippet provided below). If you mean changing the TYPE of the wire, that's a silly question since that can't be done. Doing that requires a recompile of the VI.
  18. The bolded statement is rubbish, I'm sorry. I have a use case. In order to create a branching execution order in my event-driven code, I create entirely new registration refnums for a branch, swap out the event registration wires, execute the branch (which may itself branch....) before returning to the original queued up events. It's a rare use case, but it does exist and is powerful. It also adheres to all of LabVIEW's semantic rules of how things should work. I was reading the thread for a while and thought I was going to side with Shaun, but after looking at the code which he posted, I have to side with the others and say it's clearly (and I mean really clearly) an illegal buffer reuse compiler bug which has been fixed, and that's good. The semantics of the code dictate that the Event Shaun wishes to fire should never be handled in this code. The event registration refnum can be changed in every iteration of the Event structure. That's dataflow. The prototype of the Event Structure must remain constant but the actual event wueues handles within can be altered and substituted at will. Swapping out the Event registration refnum and wiring up new references to the existing refnum (as mentioned elsewhere in the thread) are NOT the same thing. Wiring up a new reference to an existing Registration refnum changes the event source for that event queue, but leaves all existing events in there. Swapping out the event registration refnum actually changes the event queue. Both of these should work and both of these adhere perfectly to dataflow.
  19. What I found helped int eh past was to generate the text texture myself for application. By creating a much larger texture than required, resulting in each letter being many pixels wide, the effects you are seeing were significantly reduced. Shane
  20. How do you instantiate the text int he first place? Texture?
  21. The only thing I can think of is to make the text more than a single pixel wide..... Otherwise antialiasing is going to do that to you. Of course, YOu can try turning off the Antialisaing for the object in question..... "Specials: Antialiasing"
  22. https://www.opengl.org/archives/resources/faq/technical/polygonoffset.htm Available as "PolygonOffset" for a Scene Object in LabVIEW.
  23. If you position objects at the same depth from the camera, you're leaving the choice as to which draws "front" up to rounding errors of the SGL datatype. Put a minimal depth difference between them. IIRC, there's a property you can set in order to force this.
  24. I personally don't like "chaotic" (In a maths sense) because chaos results from incredibly complex physical systems which are complex by definition whereas the code is typically complex by implementation. IANAM (I am not a Mathematician)
  25. I recently watched a few Presentations on "Technical debt". I suppose you could say that bad code is beneficial in itself (assuming it works), but with high interest. If you don't come back to fix it, eventually it will bankrupt you. Or if your audience is male-only, the phrase "High maintenance" might work. I hesitate to add this term because it's often used in a very non-technical way which may offend some.
  • Create New...

Important Information

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