flintstone

Hi, I have the problem that the projects that I and a colleague developed cannot be built by our automatic build system, there are VIs missing which are part of an lvlib which we created. I managed to reproduce the problem by checking out to the same path as the automatic build does and there the lvlib does not find it's VIs either. Looking into the lvlib file with a text editor I saw paths (or URLs as they are called there) that equal our development environment. For trying I changed them in the text editor to the location where the build shall happen and, voilà, the lvlib would find it's VIs again. So these URLs are for sure absolute paths which are used to find the VIs. But from what I've read I understood that the lvlib (at least outside of vi.lib and user.lib) stores relative paths, so either I didn't get the point or something goes wrong there or it's a LV bug. Whatever it is but I really need to get this working so one option is to change the paths for the time being to relative paths. I tried with the format "./<subfolder>/<VI name>" but the dot is then replaced by the library name (which is, of course, not a valid directory). Does anybody know how to enter there a valid relative path? Thanks and cheers, flintstone

Thanks, when looking at the picture it seems like it is the same box (only for double the price ).

Hi, today I received a newsletter for the NI USRP platform so I looked a bit into it and now I wonder what kind of hardware this is. When comparing with the USRPs sold by Ettus Research which is the "standard" USRP supplier it seems that the NI 2920 USRP is either the USRP N200 or N210, the only visible difference from outside is the NI logo vs the Ettus logo. I'm really curious about this, does somebody know which hardware the NI USRP is? Best regards, flintstone

@shoneill: I guess it really depends on the task you are working on. A hard real-time system is defined as a system where the correctness not only depends on the correct values being produced but also on keeping the timing bounds. At university I did a course on worst-case execution time analysis of programs and, in one step further, programs that execute in constant time. For these systems you give up optimal best-case performance in favour of guaranteed upper bounds for execution time. The people there work on annotation systems for code to be able to communicate these requirements to the compiler directly in the code. So there are people who consider timing performance as something they want to use a compiler for. As I am a big friend of compile-time checks I definitely like this idea. I also like strong static typing a lot, it may mean more work in the beginning but for large systems it definitely pays off in the end when there are a lot of types around that sound similar and thus tend to get mixed up (I've seen this happen in more or less every weakly-typed system as soon as the complexity is above a certain point). So for any kind of restriction on return values I would definitely go with strong static typing, especially when this is a framework to be used by other programmers. If I document "Do not return something outside the range m-n" I have to rely on the user to read, understand and follow this guideline. If I provide a type which is restricted to this range don't have to hope I have a good guy there who reads the documentation ... he/she will need to anyway as soon as the stuff won't compile not matter how hard they try. Cheers, flintstone

@Aristos Queue: Of course a parent class has to limit the way the child classes behavior but wrong restricitions will lead to unusable results. I'll give a made-up FPGA example (all Altera stuff): You designed a component, that takes a stream of input data, processes them and outputs them as a stream again. Your implementation needs n clock cycles until output data starts so you restrict all derived code so that it must present data within exactly n clock cycles. Now somebody wants to derive from that code and attach it to an FPGA soft-core processor (NIOS). He adds the necessary stuff for an Avalon-ST interface but this consumes another clock cycle. This is no problem for the system, which uses streaming interfaces everywhere, the Avalon-ST and the NIOS drivers will do everything for you. The "n clock cycles" restriction is obsolete now, yet it prevents the code from being used. This is, as I said, made up because OO programming for FPGAs in textbased languages is not used apart from the simulation realm. But it's a perfect example for how the world of FPGA programming changed and the way components were done some years ago does not fit todays way of building systems there. Cheers, flintstone

And still the STL is one of the mostly used programming libraries around, might have a bigger user base than LV overall. @topic: I do not get why a parent class should give restricitions to a derived class. What problems can be avoided by that? The child class may still implement the functionality errornously. And you as the parent class designer do not know now what your class might be used for in e.g. three years from now (if you still can open it in your then current version of LV ). If the child class programmer does it wrong, that's it, now flag will give you any additional safety there. Cheers, flintstone

Hi James, loads of thanks for giving a convincing explanation for that problem :) . I will investigate my options but I'm pretty sure we will find a way now. Cheers, flintstone

Thanks James for your reply. I think this is where I've had problems, due to this thingy http://lavag.org/topic/16218-lv-fpga-master-typedef-not-found-issue/ I had to rebuild everything at the deployment site but did not download it again to the flash (after all the FPGA design is expected to work the same apart from P&R subtleties) and then, of course, the FPGA VIs won't match anymore. Sometimes I wonder if I've just worked too long with FPGAs to use LV FPGA . Cheers, flintstone

Hi, using the onboard flash with our 785x's is exactly what I want to do but up to now I only managed with "Open FPGA VI Reference" containing the bitstream and downloading it to the FPGA. Are there additional parameters to give to the "Open FPGA VI Reference" VI or is this the wrong approach? Cheers, flintstone

Just to give an update on this: We are in contact with NI, the standard cables are not halogen free, there are several costumers interested in halogen free cables, NI is exploring the possibility of manufacturing those provided the quantities requested are large enough. We are still exploring here, we have already spent several k Euros on cables, replacing them with other cables will mean in the end ~15 k Euros for cables ... this is definitly too much. Cheers, flintstone

Hi, I am trying to find information on whether NI cables are halogen free and/or fire retardant. The cables we currently use are NI types SHC64-64-EPM, SHC68-68-RMIO, SHC68-68-RDIO, SH68-C68-S and SH100-100-F. Does somebody know whether this is stated in some datasheet, I didn't find it up to now. Cheers, flintstone

D'oh, I forgot to write back on this topic, sorry! We will solve the problem now by using backplane connectors for PXI and measure directly on the connector, maybe we modify it a bit for that. Should work for what we plan and be pretty cheap. @James: I also thought about using one of our FPGA cards for that but I assume that there is bus driver circuitry between the FPGA and the backplane. Our test aims to verify that our contractor managed to leave the backplane lines on High-Z if configured for it (with different configuration it will drive the real-time trigger bus), so this is not clearly in the digital domain. I would therefore not trust the result I get from the FPGA back in this situation. For many other types of measurements I would just do as you proposed. Cheers, flintstone

Hi, I am searching for a nice solution to measure the PXIe bus signals (the single-ended signals like the real-time trigger bus, no need/equipment for measuring the data transfer). The reason is that we want to verify one of the modules built by a contractor behaves correctly with regard to these signals. The easy solution I was thinking of was to have an extension card that I can insert into the rack and it routes the signals to a multi-pin connector where I can attach an oscilloscope and also connect a signal pin with a supply pin using a pull-up resistor. But I do not find this type of card, maybe because the search keywords I use are bad. Do you know of a supplier that produces such cards? Or do you typically use other ways if you want to measure the PXIe bus directly. Cheers, flintstone

Hi to everyone, I have a design on a 7851 that is working in the lab and now there is one big issue. The system consists of this FPGA card in a PXIe crate with an 8133 controller which on startup configures the FPGA using the "Open FPGA VI reference" VI, parameterizes the FPGA and receives data from it. The "Open FPGA VI Reference" points to the bitstream and was configured to generate a typedef from the interface. The application on the controller uses LVOOP, the class has in its private data control an instance of this generated typedef (actually it's a bit more complex due to other reasons, the private data only holds a reference to the cluster that holds all the data including the FPGA VI reference, but I don't think this makes a difference). Using this instance and the FPGA Read/Write nodes as well as a DMA FIFO the host application interfaces the FPGA. Within the FP interface to the FPGA there is also a cluster holding some numeric and boolean values, lets call it "param_cluster". The problem is now: I developed it in the lab where it was tested to work. I committed it to SVN (which is used to manage the whole project, essential building block of everything). When I check it out at the teststand to deploy it FPGA Read/Write nodes to "param_cluster" are broken, the error message is "Error: Master Copy for Type Definition could not be found". It's exactly the same error as in this thread http://forums.ni.com...nd/td-p/1496866 . Pitifully there were never clear answers to this. A temporary solution to this problem is to rebuild the bitstream at the teststand and reopen it in the "Open FPGA VI Reference" VI but this cannot be done in the final system. The bitstream used then must be the one tested and verified in the lab. So anyone has in idea what is happening there? Cheers, flintstone

@Aristos Queue: It is the Wait Reference.flx. @rolfk: I did quite some VHDL programming in the past years and am confident about my skills there but I'm with LV now for some months and then you never know whether there is some hidden knowledge behind stuff like this .

Thanks for your replies. Unsigneds really are not too complicated (could be that my hw developing experience from the past years helps me there a lot). Good to know that LV uses binary numbers just as the rest of the world does. Cheers, flintstone

Hi, I found the code snippet I attached in a Flexmotion VI and it checks for counter overflow by subtracting the two unsigned long timestamp values and testing whether the result is <0. Now I've tried a similar construct at my machine and it behaves just as expected: The 32 bit counter rolls over as it should but since we are testing an unsigned value to be <0 the test never gives result "true". Since the code in the "false" branch simply uses the result of the subtraction that should not be a practicat problem but I am wondering whether there is some clever trick behind that or if that is just the useless. Cheers, flintstone By the way: Sorry for the double "just" and for the (succeeded) experiment whether one can rate the own topic.

Thanks James, I thought of maybe some change in the building process that does not require the files to be copied any more and thus the issue does not pop up any more. As soon as I have time (let's see when that might be ) I will test whether this works and tell the result here. Cheers, flintstone

Hi, does anyone know about this problem: http://digital.ni.com/public.nsf/allkb/5C8FBCA58E07BB208625767E005429D7 ? We have code here that was done with a development system patched as described in the article, the consequence is of course, that we now have to patch each development system where we want to build this. On the other hand if I just replace the VIs concerned on my unpatched system with the original ones the application can be built, so I do not see an error here. Nevertheless the VI names still contain the forbidden "/". Is this a fixed issue? Best regards flintstone

Oh, I have to apologise I did not find this although it is the first thing I should have checked ... shame on me. But it brings up a second question: "When the Open FPGA VI Reference function first executes on the block diagram, it checks whether the compiled FPGA VI already exists on the FPGA target. If the compiled FPGA VI is not on the FPGA target, the Open FPGA VI Reference function downloads the compiled FPGA VI to the FPGA target. If you select Open and Run from the shortcut menu, the FPGA VI starts running if it is not already running." This sounds to me as just downloading a bitfile would not help as the Open FPGA VI reference will overwrite it if it does not match the one compiled in. Maybe using the build specification approach is really the best. Thank you!

Hi, me again . I am currently in big confusion about the way LV stores the FPGA configuration bitstream for a RIO device. As mentioned in other posts I have a setup where my project is transfered to a PXI controller where some SW framework loads it in a plugin approach. My project employs a R series FPGA board. I had some confusing experiences with this where the oscilloscope showed clearly different behavior than what the implementation should do. After some time I noticed it was seemingly and old bitstream used. I then introduced a revision number for my FPGA design that is set to a constant in the FPGA top-level VI and actually I saw that there was the wrong bitstream being loaded. The way I do it is with the "Open FPGA VI Reference" VI that is configured to use a bitstream. The bitstream is actually copied to the build destination directory and is the latest according to the timestamp. But I doubt that really this bitstream is used because a) I once deleted it on the target system and my design would still boot happily boot without throwing an error when calling the Open FPGA VI Reference VI and b) my VI that calls the Open FPGA VI Reference VI is about 1 MByte big. Somehow I have the feeling that the FPGA VI is compiled into this VI although this is not stated anywhere. So the question is what might I be doing wrong here or whether this is the way it is supposed to work. At the moment every time I did a new synthesis of the FPGA is explicitly open the "Open FPGA VI Reference" VI configuration dialog and point it to exactly the same bitfile and with this I have not seen a "wrong bitstream" problem but it is not nice to do so. Best regards flintstone

I guess this would also break the version where the IP address is used instead of the DNS name.

I thought about this but I guess that could slow down the performance of my application and of course I do not want that. Cheers Flintstone

Thank you James for this link, this seems to be exactly the problem I am facing. During FTP upload it looks like the list command starts to time out at some point. So I guess I'll have to start thinking about reducing the number of files, e.g. by using libraries. Regards Flintstone

Hello, since this is my first post here I start with a welcome to everybody! Now for my problem: In our project for LV RT we use a LV framework that requires me to build the project as source distribution and save it to the PXI controller where it is loaded on next boot-up. So essentially I have now a folder containing ~2500 VIs totalling to ~50 MByte and I want to load it to a 8133 controller via FTP. The problem is that the transfer starts at acceptable speed (>150 KByte/s) but becomes incredibly slow after the first ~1000 files are transferred (< 5KByte/s). I have tried up to now with three different FTP clients (Filezilla, WinSCP and the FTP client in LV MAX) and from two different machines. It seems to be connected to the number of files in the target directory. I managed to upload the source distribution by manually distributing it to four target directories but now again moving the contents of the four directories to one on the server with WinSCP takes ages. Even if this would work doing this manually is really no solution as it is error-prone and way too slow. Am I missing something here or could the number of files in the target directory really be such a performance problem. Any recommendations? Best regards flintstone