Re: [Xenomai-core] Analogy DIO data acquisition with NI6259
Hi, On Wed, Sep 14, 2011 at 5:38 AM, Stefan Schaal ssch...@usc.edu wrote: This is a summary and conclusion of using a NI6259 with Xenomai/Analogy for digital data I/O. First of all, many thanks to Alexis whose Analogy branch really allowed us to succeed! We would just like share the final results of our implementation with the hope that this might help others. Goals: We needed a 19 bit parallel I/O for bi-directional communication between a host computer and a robot controller. The 32bit DIO of the NI6259 seemed to well suited. The communication protocol needs about 300 DIO commands per ms, where every about 20 commands the DIO port needs to switch from write to read and then back. Problems: Initially we tried a4l_sync_dio() (synchronous communication). We measured that one a4l_sync_dio() takes about 5us. Additionally, the switch from read to write mode also seems to take some additional time. Thus, the communication speed was not sufficient. A 2nd attempt was to use instructions and instruction lists using a4l_snd_insnlist() and a4l_snd_insn(). We measure that this can bring down one data acquisition to about 3.5us when all commands are queued up in an instruction list, but due to the read/write switch we needed, we cannot use very long instruction lists, and the read/write switch takes too long. Thus, the communication speed did not improve a lot. A 3rd attempt was to use CMD structures. Following comedi examples, we create a 200ns clock and triggered the CMD streaming with this clock. This allows VERY fast DIO. But, again, the read/write switches that are needed frequently made CMD structures inefficient as we could not cue up a lot of DIO commands before the next read/write switch, and in order to do the read/write switch, the CMD has to be aborted. We also noted that starting a CMD has some delays. We realized that none of these approaches was feasible. Solution: We create a simple IC-based circuit that allowed to branch the read/write DIO protocol such that we could use one DIO channel of the NI6259 for write only (never switched to read), and the 2nd DIO channel on the NI6259 for read only (no switching). By avoiding the read/write switching, all three ideas from above are possible and run fast enough (after some optimization of our communication protocol). We ended up using a4l_sync_dio() as it is the easiest to use, and yielded sufficient speed. With the CMD approach, we would be able to go a factor 5-10 faster even. For you info, our interface C-code is attached. This is not general purpose software, but should allow other to get the idea of what we do. Many thanks for this feedback! Best wishes, and thanks again to Alexis! -Stefan Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Analogy DIO data acquisition with NI6259
This is a summary and conclusion of using a NI6259 with Xenomai/Analogy for digital data I/O. First of all, many thanks to Alexis whose Analogy branch really allowed us to succeed! We would just like share the final results of our implementation with the hope that this might help others. Goals: We needed a 19 bit parallel I/O for bi-directional communication between a host computer and a robot controller. The 32bit DIO of the NI6259 seemed to well suited. The communication protocol needs about 300 DIO commands per ms, where every about 20 commands the DIO port needs to switch from write to read and then back. Problems: Initially we tried a4l_sync_dio() (synchronous communication). We measured that one a4l_sync_dio() takes about 5us. Additionally, the switch from read to write mode also seems to take some additional time. Thus, the communication speed was not sufficient. A 2nd attempt was to use instructions and instruction lists using a4l_snd_insnlist() and a4l_snd_insn(). We measure that this can bring down one data acquisition to about 3.5us when all commands are queued up in an instruction list, but due to the read/write switch we needed, we cannot use very long instruction lists, and the read/write switch takes too long. Thus, the communication speed did not improve a lot. A 3rd attempt was to use CMD structures. Following comedi examples, we create a 200ns clock and triggered the CMD streaming with this clock. This allows VERY fast DIO. But, again, the read/write switches that are needed frequently made CMD structures inefficient as we could not cue up a lot of DIO commands before the next read/write switch, and in order to do the read/write switch, the CMD has to be aborted. We also noted that starting a CMD has some delays. We realized that none of these approaches was feasible. Solution: We create a simple IC-based circuit that allowed to branch the read/write DIO protocol such that we could use one DIO channel of the NI6259 for write only (never switched to read), and the 2nd DIO channel on the NI6259 for read only (no switching). By avoiding the read/write switching, all three ideas from above are possible and run fast enough (after some optimization of our communication protocol). We ended up using a4l_sync_dio() as it is the easiest to use, and yielded sufficient speed. With the CMD approach, we would be able to go a factor 5-10 faster even. For you info, our interface C-code is attached. This is not general purpose software, but should allow other to get the idea of what we do. Best wishes, and thanks again to Alexis! -Stefan ni6259_interface.c Description: Binary data ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Analogy DIO data acquisition
Hi, Sorry for the late reply. Happy new Year!!! Stefan Schaal wrote: Hi Alexis, I was wondering whether you could help me with some information about CMD based data acquisition in analogy. You might recall from previous emails with you, we are trying to implement high speed data DIO communication with a NI6259 board. We use the CMD structure to create a periodic task, that is clocked by a timer, to achieve the required communication speed. As we need to change the R/W polarity on some channels every 20-30 scans, we need essentially to find out when the data in the communication buffer are consumed, such that we change polarity and trigger the next set of acquisitions. Currently, working with the MMAP options seems to be the best way of handling this. I just had some questions concerning how to detect when the data are consumed. It appears that the periodic task is automatically canceled when a DMA underun is discovered (as can be checked with dmesg). Is this automatic canceling behavior the officially correct behavior? I can use a4l_poll to find out how much data is left in the communication buffer --- I noticed that it returns -EPIPE when the data buffer has been consumed, which also seems to indicate that the periodic task has been canceled. (So for, the -EPIPE return code is not documented in Analogy). In my TODO list, there is something which might satisfy your needs. Once, someone asked for getting awoken only when a specific amount of data has been made available by an input subdevice. Gilles proposed the use of a specific ioctl to configure a wake-up threshold. I kept his idea and put it in my list. I just have not found the time to implement it yet. I think this ioctl could suit your needs because it could work for both input and output asynchronous subdevices. If you want to implement it, you are more than welcome. Or else, I am currently finishing something D. Nicolodi proposed a few month ago and I will implement just after (the counting subdevices will wait a little bit more). At first sight, I think this task should be feasible quite quickly; the poll ioctl handler just has to be rewritten. I am running your latest Analogy branch. Be careful, the wf_* tools are not complete. I was just wondering whether my observations are correct, and that it makes sense to develop more communication code by using this behavior of Analogy. Best wishes, and Happy Holidays! -Stefan -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core