Jordan Kuehn
-
Posts
690 -
Joined
-
Last visited
-
Days Won
21
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Jordan Kuehn
-
-
Is your amplitude correct? It looks like you are trying to command nearly +/-2000V output. Also you have a lot of coercion dots with your fixed points. Try to get those to be consistent. It's not as important with floats and integers, but you can get some strange stuff going on depending on how the bits are allocated going from FXP to FXP.
-
10 minutes ago, Mads said:
That would make sense if the question was whether they would support that a third party created a tool based on this type of manipulation.
I do not understand why they do not support it within the project explorer though. When they control both the file format and the editor, supporting this type of target copying would just be a matter of updating it to their new format. They already convert the project file to new versions so that part would be taken care of.
Agreed 100%.
-
I've done some of this in the past (when SCC decided to "merge" my lvproj file), and it seemed straightforward enough. I think I recall the primary reason it is unsupported is because they can change the xml structure at will. Currently I have use for this because I have one cRIO on my desk to test with and another in a system to deploy to. If only we had a way to virtualize targets, but that's a different can of worms!
-
10 minutes ago, drjdpowell said:
Unfortunately, the NXG Web module lacks both recursion and VIs for determining the data type inside a variant. This makes porting JSONtext to it very difficult.
I'm not surprised by this, but thank you for weighing in. Maybe when NXG reaches CG parity in 2050.
-
1
-
-
16 minutes ago, JKSH said:
The "Flatten to JSON" and "Unflatten from JSON" nodes in NXG WebVIs are essentially the same as the ones built into classic LabVIEW. Both are incapable of processing enums or timestamps.
As a workaround, you can create a "bridging" typedef (GType) which replaces enums and timestamps with strings. Use that with the NXG JSON parser, and then convert it to your "real" GType.
Thank you for the confirmation. I have done something similar using numeric types, but it is inconvenient at best. An NXG version of this toolkit would be fantastic.
-
I've been using this toolkit when passing data to a WebVI in LabVIEW NXG 5.0.0. It appears that the JSON parser built into NXG WebVIs is incapable of reading enums or timestamps. I am not certain if that is a limitation of the parser or the encoder. Are you able to shed any light on this drjdpowell?
-
Congratulations on this new adventure!
-
I have tried and experienced similar results. I have been able to accomplish simple tasks by calling python from the System Exec.vi with the appropriate parameters and such. It's slow, but is ok for some things. It did require using the Chroot/SSH "Trick".
-
No problem. I believe it was this toolkit: https://github.com/Indie-Energy/AWS-IoT-RESTful and the license is pretty wide open I believe. If I have a chance I'll see if I can pack it up and contribute to the project on the github.
I'm also using the WireFlow toolkit (paid) for some MQTT projects with a broker that I've set up. I was initially drawn to the Indie-Energy one even though I have a WF toolkit license since it was more plug and play for AWS. I do think now after learning more about the AWS IoT stuff that either will work, but also that I don't want to work with AWS IoT if I can help it. Note, the WF toolkit does not use the native LV2020 implementation and they do not have plans to do so. The reason I replaced the IE toolkit TLS code is because I had issues on Linux RT and that fixed it. I have not had issues in general with WF on RT, but I'm not using TLS in that application (yet).
-
1
-
-
That's not even a real address...
-
4 hours ago, Breizh_Instruments said:
Hello everybody,
Thank you for this very interesting topic.
I need to connect as a client to a broker with a certificate.
Is there someone that use the LV 2020 TLS with this client LV-MQTT ?
I have not used this particular client, but have done something similar with AWS and MQTT and a different client. I wound up stripping out all the OpenSSL stuff for the new native LabVIEW tools. Here is what worked for me during some initial tests. It may not be perfect, but hopefully it's a start at least. After that it's regular TCP Read/Write.
-
Thanks, that is almost exactly what I've taken to doing.
-
I just found this thread and have been getting hit by this pretty hard on my current project. That and classes locking when I have a typedef used on two targets. LV 2020. Is the answer really just to break my projects apart into Windows and RT? I've not had to do this in the past, but I haven't had as extensive use of classes on the RT side before.
-
18 hours ago, Renny Sadala said:
Previously, i loaded the folder containing my all classes (for example the folder Host_Class). I had placed this folder in the path /home/lvuser/natinst/bin/. I.e I will had /home/lvuser/natinst/bin/Host_Class
Now, i place directly my classes in the path /home/lvuser/natinst/bin/ and not via a directory like Host_Class.
Apparently, By default, when RT target runs, the reading is limited only to the path specified in the RT target properties. In my case, this path is /home/lvuser/natinst/bin/
You might check the folder permissions for the folder you created. I have ran into issues with that before.
-
I've used this in the past as an inexpensive insurance policy. I've never had to restore from backup though.
-
18 hours ago, Neil Pate said:
Another weird thing. When I close a project it often does not close the open VIs that are part of the project!
Maybe my installation is just busticated.
I get that one some projects and not others. I'm used to being able to close out the project and it closing everything else out and prompting to save. But I don't think that's only on 2020, I have it in 2018 as well, same projects.
-
2 hours ago, Neil Pate said:
Absolutely. This is such a good tool it is a bit sad NI does not officially endorse this.
By the way I found this thread a bit more current
In particular this post with step-by-step instructions on how to begin: https://forums.ni.com/t5/LabVIEW-Real-Time-Idea-Exchange/Provide-a-Virtual-Machine-VM-in-which-to-run-LV-RT-systems-on/idc-p/3953070/highlight/true#M598
with a bit of further info instruction here to get the embedded GUI up and running: https://forums.ni.com/t5/LabVIEW-Real-Time-Idea-Exchange/Provide-a-Virtual-Machine-VM-in-which-to-run-LV-RT-systems-on/idc-p/3953394/highlight/true#M603
Thanks for all the links. I had seen discussion some time back and had never jumped through the hoops to make it happen. Currently I have three different cRIOs on my desk which gets to be expensive. I'll give this a shot!
-
1 hour ago, Neil Pate said:
My latest weird project bug with LV2020 is when I close the project it does not automatically close any windows I had open 🤬
I was getting this in LV2018. I get something similar still in LV2020, as well as projects that don't seem to leave memory even after they are all closed out to the main LV screen. They open back up instantly.
-
I'll be honest, the very basic Event Logger Library from NI meets my needs 95% of the time. I have heard of an offering from DMC called Llama while attending one of the local user groups in Chicago, but haven't had any time to give it a shot.
-
It seems to me that it sometimes wants to open the VIPM Browser instead or if one is open the other one doesn't want to open. I need to retrace my steps to recreate the issue, but I noticed some strange behavior in the past, also in a VM. A restart got things working again too.
-
On 6/16/2020 at 12:33 PM, Rolf Kalbermatter said:
Well, one problem is that your Python script uses GPIO pin numbers while Linx uses connector pin numbers. Now the GPIO25 happens to be Linx pin 22, so you got that right. But the GPIO22 pin is the Linx pin 15 and you configure that as custom CS signal. This is wrong.
The Python script sets this explicitly to be an input and with pullup resistor. The Linx custom CS handling will set this as output and actively drive it, asserting it before every frame and deasserting it afterwards. This is likely going to conflict with whatever your hat is trying to do.
There are two things you can try:
- Set the custom CS pin for the SPI ReadWrite function to a pin number that is not connected to any pin on your hardware. That will make sure it doesn't conflict with your hardware. Call before the Digital Write for pin 22 an explicit Digital Read for pin 15. This will make sure the digital pin is configured as input. Unfortunately Linx does not allow you currently to configure a pullup/pulldown pinstate, but it may be enough to let your hardware work.
Thank you for the pointers. Unfortunately that didn't work either. Does the ioctrl c command behave differently than spidev in python?
I may be able to give this a shot again in some time, but for now I was able to use a combination of the SSH trick and calling python commands from the CLI to get things working, albeit slowly. Figured I would at least leave a note here for now.
-
17 minutes ago, Reds said:
Forget about colors and fonts, I want to better understand this quote from Austin Business news:
NI Systems Engineering
-
1
-
-
2 minutes ago, crossrulz said:
NI Week keynote. Pure marketing BS. Exactly what I expected from it.
Perfect. I know exactly what I missed. Thanks!
-
At risk of derailing my own topic I'd like to see if someone might be able to shed some light on my original problem. Below is a snippet of code that I've put together in an attempt to replicate a python routine that is not functioning properly. It works fine in python. Address is 1 and I have tried a variety of CS pins, modes, bit order, and asserting the Frame line or not.
And the Python routine attached, relevant sections below. This is for a RELAYPlate hat.
GPIO.setmode(GPIO.BCM) RELAYbaseADDR=24 ppFRAME = 25 ppINT = 22 GPIO.setup(ppFRAME,GPIO.OUT) GPIO.output(ppFRAME,False) #Initialize FRAME signal time.sleep(.001) #let Pi-Plate reset SPI engine if necessary GPIO.setup(ppINT, GPIO.IN, pull_up_down=GPIO.PUD_UP) spi = spidev.SpiDev() spi.open(0,1) localPath=site.getsitepackages()[0] helpPath=localPath+'/piplates/RELAYhelp.txt' #helpPath='RELAYhelp.txt' #for development only RPversion=1.1 # Version 1.0 - initial release # Version 1.1 - adjusted timing on command functions to compensate for RPi SPI changes
def getID(addr): global RELAYbaseADDR VerifyADDR(addr) addr=addr+RELAYbaseADDR id="" arg = list(range(4)) resp = [] arg[0]=addr; arg[1]=0x1; arg[2]=0; arg[3]=0; ppFRAME = 25 GPIO.output(ppFRAME,True) null=spi.xfer(arg,300000,60) #null = spi.writebytes(arg) count=0 # time.sleep(.01) while (count<20): dummy=spi.xfer([00],500000,20) if (dummy[0] != 0): num = dummy[0] id = id + chr(num) count = count + 1 else: count=20 GPIO.output(ppFRAME,False) return id
I write A wave signal and its anti-signal to FPGA (7851R), there is phase shift in out put
in LabVIEW Community Edition
Posted
Ah yes, you are reminding me of some specifics regarding the modules accepting integers when used in the FPGA and if the calibration mode is set to "Raw". Here are some notes I have from working with a 9263 (quite some time ago) which should be similar.
Note explicitly casting types in the host sine wave properties VI (first picture) that produces the properties for signal generation that are passed to the FPGA code (second picture). The FXP constants wired in to the casting configures the bit word lengths.
https://www.ni.com/documentation/en/labview-comms/latest/data-types/intro-fixed-point-numbers/
Perhaps you have adequately addressed this, but I've been burned on this in the past. Anyway, some of these examples might help illustrate the signal generation being done in the FPGA itself if that helps.