10-01-2015 05:39 AM
Ok thanks Sam.
But what sort of communication would you interpret from the problem?
Do you think I need to set up a terminal communication? Or is it simply the standard communication that you get between the front panel and the FPGA? Do I need to create my own ethernet or serial communication?
What sort of signal or communication would you understand from this problem?
I found this problem very open ended and non specific but I think that is because of my lack of experience so I will be interested to know what someone more experienced like yourself would understand from this problem.
I will have a look at the interaction between the FPGA and real time and see if I can pass some data between the two. I wasn't aware that they could both run simultaneously to be honest.
10-01-2015 06:11 AM
Read the guide I linked you to. Think about which methods are applicable to your problem.
You don't need to implement some custom terminal/protocol. Read the front panel controls of your FPGA VI on your RT VI and then you can either stream data using Network Streams or use Network Shared Variables to share data between your RT VI and your Windows VI.
There are lots of example projects built into LabVIEW for CompactRIO which you can replicate for the sbRIO.
10-01-2015 06:18 AM
Why can't you just setup a buffer to stream data from the FPGA to the Host PC? There's examples in LabVIEW for this. The SOM has DMA buffers doesn't it?
10-01-2015 10:30 AM
@David-Baratheon wrote:
I found this problem very open ended and non specific but I think that is because of my lack of experience
This is what engineering is about - using different tools to come up with solutions to problems which are sometimes open ended. The problem actually sounds quite well defined to me (even with very limited FPGA experience and absolutely no idea what the SOM is or what data you actually need to move around), so I'm guessing this does fall down to experience, but it seems whoever tasked you with this problem actually did do a pretty considered job of estimating the effort you need to get it done.
Note that using various resources is a perfectly legitimate strategy, but going to the forums should generally come near the end of the process, for a number of reasons. You have been given specific pointers and there should certainly be some examples, manuals and tutorials which show examples of these communication channels. I suggest you get digging with the references you got and with more searching and reading and review that content.
If there's something that's still unclear, go back to your "customer" and discuss it to make it clear. I don't think they want or expect you to disappear for two weeks and come back with a working project. I expect they will want to monitor progress. Present different options and their cost/benefits, etc. I understand you're well into those two weeks and you may think you haven't progressed enough, but the right thing to do is to involve them and let them know. I don't know them, so I can't say how they'll react, but communication is important in a team, and I expect they *want* you to succeed, since your success is their success.
10-01-2015 10:39 AM - edited 10-01-2015 10:46 AM
To be honest my workplace is pretty good so I don't feel under pressure. It was a learning exercise and in the last 2 weeks I have downloaded all the necessary software (FPGA Module, Real-Time Module etc), learned about the sbRIO-9651 hardware and learned how to code, program and test an FPGA, so I certainly feel I have learned a lot in the last few weeks. So I think my upline manager will be pleased with my progress. But it would be nice to get it finished in the time frame if it was possible.
I am currently having a look at some of the suggested methods and trying their implementation so I will see how I get on.
I am not sure I necessarily agree that engineering is about open ended problems. In my own experience I am used to very tightly defined requirements, but in this case as it was a learning exercise, loosely defined requirements provided more of an opportunity to give it my own direction and learn what I feel would be beneficial to my own progress with National instruments software and hardware so it was good as a learning exercise.
I was just interested to understand how experienced LabVIEW users with architect status would understand and approach the problem.
Regarding how the forum should be used, well from my observations that is not how the majority of people use the forum. It seems usually people usually join the forum to ask questions about a project they are stuck on. As one's experience increase, one leaves the side of asking questions to slowly move towards being the one answering them. I have an interest in solving other peoples problems here when I can get my expertise up as I would imagine that it's actually a good way to refresh and challenge and update your own knowledge. I don't think there is a specific set way of using the forum or any set of rules that I am aware of so it is really up to the individuals to utilise it the way they find most beneficial. For me I have gotten a lot of benefit from my time here so far.
10-01-2015 10:59 AM
@David-Baratheon wrote:
In my own experience I am used to very tightly defined requirements.
You are very lucky or very unlucky or have been a small enough cog in a well oiled machine. Clear requirements are great, but not all projects have them and often having some freedom makes life more interesting. It's also not uncommon to be tasked with "figure out how to do X". It's certainly possible that in your case that freedom mostly exists in higher levels which then make decisions and lock down the definitions for implementation by the software simians.
@David-Baratheon wrote:
I was just interested to understand how experienced LabVIEW users with architect status would understand and approach the problem.
In exactly the way Sam recommended - looking at different examples and tutorials, seeing how it works, running tests and making a decision. Of course, in that game your past experience plays a large role in how you go about doing this.