DTaylor
-
Posts
62 -
Joined
-
Last visited
-
Days Won
10
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by DTaylor
-
-
On 9/29/2017 at 7:55 PM, planet581g said:
Can anyone else confirm.
I can confirm as well. Parallel read-only access is broken until this is fixed.
I played around with the bug a little bit, and it appeared as though up-to-date data fails to make it out of the SubVI when parallel read mode is enabled (super weird).
-
from dmesg:
[ 7.434709] usb 1-4.4.4.2: new full-speed USB device number 24 using xhci_hcd
[ 7.577906] usb 1-4.4.4.2: Not enough host controller resources for new device state.
[ 7.577923] usb 1-4.4.4.2: can't set config #1, error -12It looks like this issue is not limited to NI Linux-RT: https://superuser.com/questions/731751/not-enough-host-controller-resources-for-new-device-state
I poked around in the BIOS and couldn't find anything that would allow me to disable xhci. Does anyone know if this is possible without recompiling the kernel?
-
16 minutes ago, hooovahh said:
but NI might and you should probably crosspost here.
But that's probably good advice. x-post here: https://forums.ni.com/t5/NI-Linux-Real-Time-Discussions/FTDI-USB-Device-Limit/td-p/3686134
-
15 minutes ago, Tim_S said:
but can run into bandwidth issues.
So I can't even get to the point where I attempt to send data to all 16 at the same time. I'm so far unable to get the OS to even enumerate all the devices.
15 minutes ago, Tim_S said:Powering a device off the USB port could cause problems as well if you exceed the current capability of the port.
I should have mentioned that the first configuration I tried was two 8 port hubs each with their own 60W DC supply.
11 minutes ago, hooovahh said:I'm curious what USB hardware you are using.
The control boards have Arduino Megas on them that I'm connecting to. I have two Anker 8 port USB hubs each with their own 60W DC supply. I connected one to each USB port on the cRIO. If I instead daisy chain them, I can see up to 14 devices enumerated from the one cRIO USB port, and when I connect a 15th board directly to the second cRIO USB port (not through a hub), nothing new shows up in /dev and there are no new devices in MAX or VISA discovery.
-
I have a cRIO 9030 based test system that connects to 16 control boards over USB (FTDI). I can connect and communicate with 14 just fine, but it seems NI Linux RT is not recognizing the 15th and 16th devices. /dev/ttyACM0 through /dev/ttyACM13 show up for the first 14 boards, but no new ttyACM files appear for devices 15 and 16. The first 14 also show up under devices and interfaces in MAX and are discoverable with VISA. I've tried a couple different hubs in different configurations connected to the two USB ports (including daisy chaining them), and I'm always able to get exactly 14 boards to connect.
I can communicate with all 16 without issue on my desktop, so I don't think it's an issue with the hubs.
Is this a real OS or hardware limitation, or does anyone know of a potential solution or workaround? If there is a real limitation, I can settle for testing two batches of 8 at a time. Thanks!
x-post here: https://forums.ni.com/t5/NI-Linux-Real-Time-Discussions/FTDI-USB-Device-Limit/td-p/3686134
-
On 8/24/2017 at 7:26 AM, Thoric said:
Does anyone know any more about creating 'actual' Windows services? I'd like to avoid this wrapper based approach which casually spins up and tears down exes.
Try out NSSM:
It's still a wrapper, but an awesome one. In the pre-release builds, you can create custom actions that run when the service is stopped (i.e. to send your application a command to stop and clean up). It's super easy to use compared to everything else I've tried.
-
1
-
-
2 hours ago, Aristos Queue said:
Most languages (Haskell, Racket, Erlang, Lisp) that are successful in taking full advantage of multicore parallel programming do not allow references.
Haskell has IORef, which along with modifyIORef/modifyIORef'/atomicModifyIORef etc functions a lot like a DVR + IPE structure. Haskell and Clojure (I don't know about other Lisps) both have STM reference implementations, which just require thread-safe transactions to update the values they reference. Rust has a strong emphasis on memory safety and "fearless concurrency", and it has several reference primitives. I think there are a lot of valid use cases for references, and I like that DVRs exist in LabVIEW.
Depending on what OP is trying to do, I do think your solution is best.
2 hours ago, Aristos Queue said:Computer science has had a better way to program since the 1940s, but Van Neumann saddled us with the IBM hardware architecture, and direct addressing of assembly and then C and its successors won performance at a time when such things were critical. Hardware has moved beyond those limitations. It's time for software to grow up.
Functional programming? Does this mean that you're going to get this idea resurrected?: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-Enum-Class-Primitive-quot-The-Defined-Enum-quot-with/idi-p/1904525
-
I have a (small) update to these nodes since I learned about the RunTimeDoubleClick ability. They now open the target VI at run time as well.
Async-Or-Show from this package has become one of my favorite things for non-reentrant UI VIs (runs the VI if its front panel isn't open, makes the target's front panel frontmost if it is open):
-
1
-
-
Like this:
SubVI Contents:
-
14 hours ago, smithd said:
In that case, maybe you can use this https://lavag.org/topic/19781-xnode-owning-diagram/ to get a ref to the VI you're dropping on and then use that vi ref to get the application context and from there go crazy with property nodes across application contexts?
This works, but I think he'll also have to put Get LV Class Default Value by Name and Get LV Class Path into a SubVI - let's call it Get LV Class Path by Name. He'll then have to open a reference to that VI with the appropriate application reference and do a call by reference. Then he can go crazy with property nodes across application contexts.
-
2
-
-
On 7/15/2017 at 0:25 PM, UnlikelyNomad said:
Then I get the daunting task of scripting up the GenerateCode ability >_>
When you do this give LV-Scripting a chance: https://github.com/erdosmiller/lv-scripting
It has similar functionality to the LAVA Scripting Library: https://lavag.org/files/file/54-scripting-tools/ , but with a heavy emphasis on ease of use for code generation. The package has a dozen or so examples which likely cover everything you need for your XNode.
-
I think it's extremely useful. I added DVR support to the latest version of LV-Signals which does something very similar:
It only works with DVRs of clusters, and it looks like yours works with DVRs in general. Check out LV-Signals if you get a chance, the original use was to use it with LV-Create-Signals.xnode, which creates a DVR and a value change event for each element in the cluster.
-
1
-
-
Neelex,
You're right, there isn't a way to do what you're looking for as it is. I'm in the middle of a big project right now, but next time I have the chance I'll see if there's a nice way to get that kind of functionality in there (may not be 'til after summer).
-
Well that property was never made to work. It always returns an error. But apparently there is an application delay drawing method:
-
I search for an hour and find nothing. So I post here, and two minutes later I find the private Defer Diagram Updates property.
-
1
-
-
When doing lots of updates to a block diagram via VI Scripting, like adding/deleting several things or moving things around, is it possible to lump all the operations together so the user sees it all at once (like what you can achieve on front panels at runtime with the Defer Front Panel Updates property)? I've spent awhile searching online and rummaging through properties and methods but can't seem to find anything.
-
12 hours ago, lordexod said:
In LV NXG you have more capabilities than you had in LV TG because you can make abstraction layer for XNode, XDiagram, XTunnel, XWire, components as native plugins.
Is this speculation about something that you think we should be able to do in NXG, or is this functionality that you've heard is actually planned?
-
This is an experimental set of XNodes that puts a set of values in a DVR, lets you access them, and generates user events when one of the elements changes.
LV-Create-Signals.xnode takes a cluster at the input, and outputs a cluster of a DVR with the input cluster in it, and an event for each element in the cluster. The output can be bound to an existing typedef by right-clicking on the node.
The data is accessed via LV-Read-Write-Signals.xnode. It's similar to a property node, and allows access to cluster elements, array elements, and array subsets. If you write an element and change its value, the corresponding event is generated.
Attached is a VI package that will add these nodes to your palette, along with a scripting library that these nodes depend on. LabVIEW 2015 or later is required.
The source code can be found here: https://github.com/erdosmiller/lv-signals
I made these because I commonly use a DVR & user events for exposing data from a module. Let me know what you think!
-
1
-
-
This tool is awesome. I used Aitor's for a long time until a coworker shared this with me after your presentation at NI week last year. It's nice to have access to the newer abilities.
-
I always loved this idea exchange idea to add sum types to LabVIEW: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-Enum-Class-Primitive-quot-The-Defined-Enum-quot-with/idi-p/1904525
I was sad to see that it was dismissed as being classes. I think there are differences, and that having these kinds of types in LabVIEW could be nice, so I jank implemented them using XNodes:
LV-Define-Tagged-Union.xnode takes an enumeration and a cluster as inputs. If certain enum values have data associated with them, the cluster should contain an element with the appropriate type and the same name as the corresponding enum selection. The output of this node is an enum & variant cluster or "tagged union". This output can be bound to an existing typedef by right-clicking on the node.
LV-Construct-Tagged-Union.xnode takes a tagged union created by the define node at the top input and gives you a drop down menu. The input type adapts appropriately.
LV-Case-Tagged-Union.xnode goes inside a case structure. It's output type adapts based on the frame it is in.
Source code can be found here: https://github.com/erdosmiller/lv-tagged-union
I've attached a VI package that will add these XNodes to your palette, along with a package that will install a scripting library that this depends on. I wrote this awhile ago, so I don't remember all the details, but some types like .NET references may not be supported yet.
LV-Tagged-Union requires LabVIEW 2015 or later. Let me know what you think!
-
1
-
-
- Popular Post
- Popular Post
I've developed a few experimental XNodes to assist with running VIs asynchronously.
The ones pictured here are LV-Async.xnode and LV-Await.xnode. You can drag a VI onto LV-Async. It will open or check out (more on this later) a VI reference with code x100. LV-Await.xnode will Wait on Asynchronous Call, but instead of closing the reference it will check it in to a lookup table to be later used by LV-Async.xnode. The benefit of this is that when used with a reentrant VI, the asynchronous hierarchy will not go idle, so reference types created in the hierarchy will not go bad. There is an example in the VI package that demonstrates this behavior. The downside is that the memory the hierarchy uses does not get freed (subsequent async/await calls do not leak memory though since the hierarchy is being reused).
LV-Async-And-Forget.xnode opens the VI reference with code x80 and closes it after running the VI asynchronously.
LV-Async-Or-Show.xnode is meant for non-reentrant UI VIs. If the VI's front panel is not open, it will run the VI with option x80. If the front panel is open, it will bring the front panel to the front.
Attached is a VI package that will add these nodes to your palettes, along with a couple package dependencies.
Source code for LV-Async is here: https://github.com/erdosmiller/lv-async
LV-Async requires LabVIEW 2015 or later. Let me know what you think!
-
6
-
- Popular Post
- Popular Post
Attached is a VI Package that will add LV-Control-Refs.xnode to your palette. This node, when dropped on the block diagram or double clicked, will update its output to a cluster of references to all controls in the VI. Controls in tabs show up as <Tab Control Name>:<Page Name>.Control Label. Nested tab controls with arbitrary depth are supported. You can bind the output of the node to an existing typedef by right-clicking on it.
I've used this node for awhile, but the tab support was added very recently and was a significant change. I've also attached a scripting library I maintain that this XNode depends on.
And source for the scripting library is here: https://github.com/erdosmiller/lv-scripting
I wrote this node because several times I've found myself bundling nearly all the control references in a VI into a cluster. It requires LabVIEW 2015 or later. Let me know what you think!
-
5
-
This random person on stackoverflow says that being able to set the back-calculation coefficient is important:
" Back Calculation highly depends on the back calculation coefficient
Kb. If you don't know how to actually calculate the parameterKbdon't use back-calculation. "I have no idea whether this is true or not, but the NI PID.vi effectively has a constant Kb of 1.
-
40 minutes ago, infinitenothing said:
It looks like NI is using option 5 on the wiki page.
They are indeed - thanks for the external reference. I've found some more references to this method. It seems potentially problematic to me, but it seems there is precedent for it.
40 minutes ago, infinitenothing said:You seem to like option #4
Not exactly. I'm not advocating for limiting the error accumulator, just stopping it in the appropriate direction when the controller is saturated high or low. It's the second method (clamping) listed here:
https://www.mathworks.com/help/simulink/examples/anti-windup-control-using-a-pid-controller.html
I'm not sure I'm allowed to link to Simulink documentation here. That may be an unforgivable LabVIEW sin.
46 minutes ago, infinitenothing said:Maybe an enum selector input would be a nice feature
That's a good idea
XNodes Prevent Inlining
in LabVIEW General
Posted
It seems that using an XNode in a VI in which inlining is enabled always generates the error: "This object is not allowed in a VI on which you enabled inlining. Disable inlining or remove this object." Is this always true, or is there some XNode ability that would allow it to be inlined?