03-21-2013 06:03 PM
Hey Bryan,
Are your teeth not all spaced evenly with the same size? From your request, my first thought is that the N Teeth M Missing Generation may better fit your needs.
If they are all evenly spaced with some missing, did you choose to use the Fully Customizable Generation because it was easier to take a pre-existing table of waveform transition angles?
Regards,
Mike Lyons
03-21-2013 06:40 PM
Nope, it is a very interesting pattern 🙂 Fully Custom is the only way!
@lion-o wrote:
Hey Bryan,
Are your teeth not all spaced evenly with the same size? From your request, my first thought is that the N Teeth M Missing Generation may better fit your needs.
If they are all evenly spaced with some missing, did you choose to use the Fully Customizable Generation because it was easier to take a pre-existing table of waveform transition angles?
Regards,
Mike Lyons
03-21-2013 07:28 PM
Thanks for the response. I put 32 as the limit because I was trying to be conscious of memory use by the IP for multi-cam scenarios. I figured that 32 teeth would be enough to catch the majority of the interesting patterns. Do you have any insight into what would be a more appropriate limit. Is 128 most likely adequate, or do you think we should have different IP blocks that have different memory depths? Maybe a small, medium, large memory use and we could roll them into a polymorphic. Let me know what you think.
Thanks,
Mike Lyons
03-21-2013 07:48 PM - edited 03-21-2013 07:52 PM
@lion-o wrote:
Thanks for the response. I put 32 as the limit because I was trying to be conscious of memory use by the IP for multi-cam scenarios. I figured that 32 teeth would be enough to catch the majority of the interesting patterns. Do you have any insight into what would be a more appropriate limit. Is 128 most likely adequate, or do you think we should have different IP blocks that have different memory depths? Maybe a small, medium, large memory use and we could roll them into a polymorphic. Let me know what you think.
Thanks,
Mike Lyons
Honestly, I don't know. I dont have enough experience in the Subject Matter to make a good recommendation.
I would say, anyone who is savvy enough to be using this toolkit (ie FPGA programming) could easily fix this. Then I would recommend mainly documenting the fix. Now that i type this all out and think this through, this is probably the best solution.
If someone is just blindly trying to create FPGA to fit in with the Engine Sim CD, then it may be a barrier. Maybe there is room for some pre-configured FPGAs to Fit with the CD. But there are a lot of hardware target combinations to support.
01-24-2014 03:45 PM
I have spent the past several days troubleshooting some weird data output I've been getting with NI's AES library. I've attached a presentation below explaining what the issue is. The cam output will stop after the first half of the first engine cycle, then begin again during the second half of the second cycle, then it's fine from then on. I need that first cycle for startup testing. I made a fix to get me going for now, but perhaps an update can be made to AES or perhaps I am not using it correctly?
Thanks,
Tim
01-27-2014 11:54 AM
Tim,
Thank you so much for your detailed description of the issue. I agree, that is a bug. I apologize that it affected you!
Amazingly though, I posted an update (2.7) on January 20th... four days before your post. That fixed the issue by wiring in the true/false from the caller instead of figuring it out at run time. So it was fixed then.
It is rare I get in a fix right before a customer reports the issue. How cool!
Take care,
01-27-2014 11:57 AM
Great! Thanks.
03-25-2014 06:52 AM
Dear Sir,
I have an ECU test platform that is based on the following hardware items:
cRIO-9074, AI 9205, AO 9264, DIO 9264
The software version is LV 2013.
I have a problem with the cRIO AES application regarding the “Single CAM Generator Loop”.
Attached are 2 images taken on the Mod3DIO5 line that is the FPGA node for the CAM signal.
Note that the project structure resides under:
Root:\Irit Files\ATP Tester 3\ATP Tester 3\ATP Tester\NI Irit\engine simulation test
Analog Output_16 Single Cam (Host).vi : Serves as the Labview RT host application.
This VI includes the input array for the cam offset angles (Name: Array).
a. I have tested (probe) the path of the cam angles array from this host VI to the FPGA VI and verified that it looks good. I have tried several array sizes (No. of angle values) and got the exact response under the FPGA target VI “ATP Single Cam Simulator.vi” in the “Cams.Num.Angles” variable.
In addition, “Cams.Data” value displays several values during operation.
However, I cannot see steady cyclic wave pattern on the cam output line MOD3DIO5.
Attached are 2 images taken on the output line during the initial application launch. One image is for an array of 4 angle values (2 pulses), and the second is for 8 angle values (4 pulses).
The cam generation process happens only once! I need it of course to run continuously.
The images were taken only after full power-off of the cRIO chassis, and the pulses can be seen only once following the launch of the host VI. Later on, the cam output line remains HIGH.
Can you please send a sample code for generating this CAM pulse train?
Regards,
Menachem Lerer - Elbit Systems - UAS - UEP
03-25-2014 09:44 AM
Hi mlerer,
I don't see any attachments. Can you attach your images and your code so I can take a look?
Thanks,
03-26-2014 01:21 AM
Hi,
I hope this time the attachments are there.
\\NASTOR01\PROFILES\DOWNLOADS\DP74319\UN_Irit Files.rar
\\NASTOR01\PROFILES\DOWNLOADS\DP74319\UN_IMG101.jpg
\\NASTOR01\PROFILES\DOWNLOADS\DP74319\UN_IMG100.jpg