Request time stamp from DAQmx using Python

[walkercheung7]

Hello Pros,

I am totally new about NI products and DAQmx, and I have several questions about the time stamp that I want to confirm.

1. Chassis cDAQ-9185 would provide time stamp to DAQmx?

2. DAQmx available free download, as well as the python API ( I found from the doc say it can be download from pip, but not sure do I need to purchase any license for python development)

3. From the NI knowledge database, back in 2018, "How to Get Timestamps with NI-DAQmx in Python"

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kJy2SAE&l=en-US

Is this still apply to the python API? there is no way to get the timestamp from DAQ chassis by python, unless use full version of LabView??

Sorry, I may not explain the question well enough as I am not fully understand every, 

Thanks,

Walker

[Bob_Schor]

Using DAQmx in LabVIEW, complete with TimeStamps (put there by your DAQ hardware) is so simple that to layer another language on top of it (which, one hopes, simply calls the DAQmx code itself) makes no sense to me.

Why don't you write a C++ routine that can call a Matlab script that calls Python that (probably) calls DAQmx to do this?  [This is definitely not a serious suggestion -- I'm just carrying the absurdity a few more levels deep ...].

Bob Schor

[walkercheung7]

Sorry I dont understand what are you trying to say.

What I try to say is I want the time stamp information to existing software,which is python based, as straight as possible.

We want to record and analysis the sound data as close as to real time. 

Sure we can use whatever language or software and make a hundreds of conversion code, however that require to build more things from sketch and more complex. Which could also create serious delay.

We do not want to spent too much time on the LabVIEW or other language if not necessary.

Therefore I am here to ask if NI a good solution for this situation.

[n7j]

I'd like to bring this thread back up. I have the same question here.

I think this is a very reasonable question to ask.

I would like to extract PTP timestamp information for sampled data from a compactDAQ using the nidaqmx Python library. Is this not possible? The Python libraries make it very easy to pull sampled data from these devices in around 20 lines of code:

https://github.com/ni/nidaqmx-python/blob/master/examples/analog_in/cont_voltage_acq_int_clk.py

I would also like to get the PTP timestamp (even just a t0) for this data from Python.

This knowledge base entry suggests is it not possible:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kJy2SAE&l=en-US

Can anyone provide insight here?

Thank you!

[n7j]

I heard back from NI support on this. It is indeed possible to get the PTP timestamp from the nidaqmx-Python library with network-synchronized devices that support PTP. It is through the nidaqmx.task.Timing.first_sample_timestamp_val property. Subsequent sample times can be calculated based on the sampling rate.

This unfortunately means that the guidance found in this knowledge base article on "How to get timestamps with NIDAQ-mx in Python" is incomplete/misleading.

Also, Bob, your dismissive tone makes for an unwelcoming environment for new community members and those browsing anonymously. I thought the question that was asked by the original poster was completely reasonable and I had exactly the same question myself. Reading through your response made me doubt whether what we were looking for was possible, and had I not been resilient enough to keep digging, I would have taken your response as authoritative. That does not help the community grow and move forward. I would encourage you to reconsider your approach next time.

[rolfk]

You address a number of things here.

First please give Bob a little credit. He is a valued member here posting many helpful posts. Yes his answer wasn't optimal to say the least. To me it sounds like he pretty much completely misunderstood the original post in a way that I can't read myself in that post. However, the post wasn't very clear describing the problem and that it was ONLY about Python and LabVIEW was just mentioned as an alternative where the thing he wanted to do was possible whereas he couldn't do it in Python. Last but not least it was posted in the LabVIEW forum and many frequent users here mainly use LabVIEW and do not know Python at all, so Bob's misunderstanding is quite understandable. Add to that a bad day, with the boss picking on you for something stupid or you wife or children pestering you about something and such a post has been sent of with the Post button before you think twice.

As to your wrong documentation, it has the tendency to be outdated the day after it was posted. If there would be more users noticing such problems AND sending off constructive feedback about it, it could be fixed quite easily (well ok, NI had since about the start of Covid until recently hidden all its employees under a rock and almost none felt compelled to spend their daily work on these forums anymore, so any feedback sent their way often felt like going into a big void where not even an echo could be heard) but generally the vast amount of documentation on the NI site only really can be kept up to date but active feedback of the actual users. No user feedback with correction requests means easily that there are either no errors in the documentation or no users using the documentation so no profit oriented company is going to spend a second thought on that documentation in both cases.

The document you refer to is obviously old and likely from the early days when NI provided a native Python API for DAQmx. At that time they implemented the basic functionality to read in data and send out data through the DAQ devices. The DAQmx API is huge and even to get that basic functionality working is a major effort. Spending time on esoteric APIs to read PTP timestamps was at that time not only not a priority but simply an unnecessary distraction. While I don't really program in Python at all it would seem to me that one of the more canonical Python API documentations nowadays for NI products seems to be on the *.io domain.

https://www.ni.com/en/support/documentation/supplemental/16/python-resources-for-ni-hardware-and-sof...

https://nidaqmx-python.readthedocs.io/en/latest/

https://nifpga-python.readthedocs.io/en/latest/

https://pyvisa.readthedocs.io/en/latest/faq/getting_nivisa.html

I can't vouch for the up to date state of those documentations but they are a good start for sure.

[n7j]

Thanks for the response. I found and shared the solution to the question in my prior post.

I will not engage any further on this matter, but I do not appreciate your attempt to make excuses for his behavior. In my opinion, a long-standing, highly-active member has a greater responsibility to model ideal behavior given their significant influence on the environment. Finally, I will link to the National Instruments Community User Guidelines, which is quite clear about the appropriateness of his response.

[walkercheung7]

Well sorry for the confusing question so that you can't read!
Seems I am the one to cause all the problem after all!

God it has been 4 years already. Mid life crisis is here for me since I got a boss picking on me for my stupid question.