communicating with an HBM t12 torque transducer

[John_Y1]

We have a brand-new HBM T12 torque transducer, 500Nm, which uses a CAN bus connection, using I believe "Profibus", to an HBM USB interface and  HBM program (T12-assist).  I would like to use LAbVIEW 7 to get data from the transducer but there are no drivers yet.
Probing about in the dll files with a "Call Library Function" node, indicates that there are some appropriate links, such as Read and Write and Status. However all this is a bit scary. Its a very expensive device!
 Could I possibly use NI CAN to talk to this transducer?  Are the basic instructions eg read data, common over the different "flavours" of CAN?

[AnkeS]

John,

I don't know how you are going to use the T12, but a short while ago we completed some testquipment using this device to measure torque and rpm.

I just looked into the forum before going on vacation for 2 weeks, so I can only give you some basic infos now:

For configuration we used the software tool from HBM that you mentioned , the "T12 Assistant". This tool required a USB CAN-Adapter from PEAK Systems.

The T12 can be accessed via the CANopen protocol. There is a manual describing the Service-Data-Objects (SDOs) and Process-Data-Objects (PDOs).

For our testequipment we used
 - NI PCI-CAN/2 Hardware
 - LabVIEW 7.1 and the
 - NI-CanOpen-Library
to read the required Data as SDO objects.
Instead of using the CANopen-Library you could also code the required messages yourself, using the NICAN Channel- or Frame-API.


I hope this helps you to get started.
I shall be happy to try and answer any more specific questions when I return to work on October 15th.

Anke

[John_Y1]

Anke
Thanks for the information.  This sounds like exactly what we need to do!   I shall investigate the hardware required.

We have a lab for efficiency testing of electric motors to 75kW (hence the 500Nm transducer) for compliance with Mandatory Efficiency Performance Standard. We are upgrading from Method B (assigned losses) to Method A which requires us to measure torque and speed under different load conditions to determine the stray losses

The present measurements are processed in LabVIEW 7, using GPIB and Serial instruments to get power, voltage, current and speed corrected for mains frequency. 

John

[AnkeS]

John,

I am glad I could help

If you have any more questions, please don't hesitate to ask!


Anke

[Replica]

Hello,

I'm also trying to use LabVIEW with T12. On my case the transducer has nominal torque of 1000Nm.

I'm using PCAN-USB adapter and PCAN driver from LabVIEW portal. I had to download newer version of the .DLL to make it work, though. The idea is to measure both torque and rotational speed, show the values on front panel and write a measurement file.

So far I'm experiencing some difficulties:

My first try was to use broadcasting-type data transmission between T12 and LV. I used PDO1, since it can send both torque and rotational speed in one package. Torque comes through just fine but speed doesn't. If I continuously read, it shows properly but when I add delay between reads (like 400ms), the speed value freezes to the value of the first package read. If I monitor the bus with PcanView, it shows that the speed value is indeed there, only the read fails. Same thing with PDO2.

On second try I used queries. I separately read the values of torque and rot. speed. This way the phasing works like a charm and rot. speed shows properly, but torque measurement gives some corrupted data (the value peaks to somewhere around 65000 when unsealed), which shows even with Pcan View.

So, any ideas how to make this work?

[Replica]

Ok, the spell check got the better of me...

Of course the peakvalue of 65k is unSCALED. And that's when there's neither rotation or load in the test motor's shaft. Normally the unscaled values are around +/- 200.

[Drew_T]

Hi Replica,

First off, it sounds like you have put in a lot of work on this already, thanks!

Did you ever see the torque spikes with the broadcast method?  If you are seeing the spikes in the manufacturer's included software, it says to me that the spikes are being generated by the hardware.  If this is the case, you may be able to filter the data to exclude these data points.

It may be helpful to take a look at your code as well; are you able to post it?

[Replica]

Hi Drew, and thanks for the fast response!

Me and my colleague ran some more tests with the programs and the results are:

The query method had the spikes in the torque value. Even if we adjust the low-pass filter, the spikes remain. If we monitor the BUS with PCANView, the dataframe has the error in it, so this is probably a problem with the T12 hardware? T12 Assistant didn't show any spikes. The speed value was ok.

The broadcasting method didn't produce any kind of spiking in the torque value but the speed value acts like the way I mentioned in my previous posts. PCANView shows that the speed value is shown on the dataframe, but PCAN-READ apparently doesn't read it.

We'll go back to research this problem and post if anything new appears. Thanks for your interest in our problem!

I attached the VIs for both methods.

[Drew_T]

Replica,

I wasn't aware that there was a time when you saw good data in one place, with spikes in another.  Does the T12 assistant communicate in the same method (PEAK Can) as LabVIEW and PCANView?

The first method (PDO1) sounds a bit more promising now that I've gone back and read the original post.  So a continuous read works correct?  What is the purpose of the delay?  Where is it implemented?  Could you post the code?

[Replica]

Drew,

The T12 assistant is using the same Peak Can usb adapter as our LabVIEW. The concept of this program of ours is to get a simple way of reading and logging data from the transducer and if needed, combine it with other measurements (not yet sure what they are, my supervisor only gave this assingment to us). With LabVIEW it'll be easy task to combine and log all measurement data into one logfile.

The delay is needed to sort of slow the measurement down. As you can see from the broadcast method.vi i posted, there is 100ms wait on the while loop when the program gets proper dataframe (The case when ID is 0x1EE representing the PDO1). If that wait is taken away and deleted, the program actually gets the value of rotational speed properly, but even with the present 100ms wait the read fails somehow and the rotational speed value freezes to the value of the first read. Torque measurement isn't affected. How is the wait actually applied? Is it applied before everything else in the case structure or after all else has been done? Could this wait be responsible for the loss of data and if so, is it possible to run the readloop without waits and still get the data phased down to more reasonable rates?

The original idea of logging the data was to add something like write measurement file -block to the case structure and the wait would do the phasing, but could the same be done otherwise?

If we don't slow the measuring down, for example measurements that last for several hours would result in massive logfiles.

We also tried to lower the PDO send rate from the transducer parameters but it's still to fast to be reasonable and with waits we get problems.

The situation is actually quite frustrating since the program works in principal, but the more trivial part of tuning the measurement rate down causes trouble we can't get our hands on. And since this is actually my first experience with LabVIEW, I'm constantly asking myself if there's something I've overlooked.

I hope this message makes some kind of sense. My workday has just started and morning coffee break is still to come.

-Replica