A Few Problems With V95 And V976

[old] bbsportz · Post by **[old] bbsportz** » May 11th, 2005, 12:18 am

MarkL Thanks for the quick response to the other POST re V976 PM3 Zeroes Here are a couple more: I make repeated calls to the PM3 device using tkcmdsetUSB_do_DDIcommand. Here is the function call in my Visual Studio C++ .NET managed DLL: public: System::Void getPM3_USB_DDI_Command(UINT16_T port) { static UINT8_T rsp_data __nogc[128]; static UINT8_T cmd_data __nogc[]={ 0xF0, // Start Frame Flag 0xFD, // Default PM3 0x00, // PC 0x1A, // CSAFE_USERCFG1_CMD 04, // Number of commands following // Commands 0xA0, // 1:Work Time 0xA3, // 2:Work Distance 0xBF, // 3:StrokeState 0xC1, // 4:Drag Factor 0x63, // CheckSum: byte by byte XORing starting from the 0x1A (#define CSAFE_USERCFG1_CMD) not including Stop frame 0xF2}; //Stop Frame Flag errUSB_DDI = tkcmdsetUSB_do_DDIcommand(port, cmd_data, rsp_data, timeout); .......} The cmd_data is the same command array that I sent in the other post. I have two rowers in the LAB. One with V95 and the other V976 PROBLEMS UNDER V95: Problem 1: What is the limit on the polling period ? I can get to 20 milliseconds (50hertz) but anything quicker than that and the PM3 crashes. Problem 2: When I am sampling at this frequency (ie 50hertz) I will make a call to CSAFE when the StrokeState is 3/4. This causes the PM3 to crash. I get around it by setting a flag and missing a DDI call on the next poll which effectively gives the PM3 some breathing space. How soon after a DDI call can I make a CSAFE call? Problem 3: I have used this call for months. It works repeatedly (when I give it enough time between calls) BUT here is the catch ..... on a periodic basis of around the 25 to 35s mark of the first minute a set of 3 to 4 DDI calls will return a StrokeState = 1 with spurious results in the other PM3Specific variable. This happens repeatedly in all countdown tests (eg 2000M, 100M, 200M, 500M etc) It appears that the CSAFE calls are OK. Have you come across this before? PROBLEM UNDER V976: Problem 4: That tkcmdsetUSB_do_DDIcommand function call above crashes the PM3 immediately when it is executed in V976. That is the code that I run under V95. When I go into the PM3APIDemo.exe with that HEX array it will not run. The PM3APIDemo.exe does however function after I pull the USB cable out and plug it back in. I have repeated this scenario multiple times. Got any ideas ? Cheers MarkA

[old] mlyons · Post by **[old] mlyons** » May 11th, 2005, 9:09 am

MarkA, I need a little more information about how you're using the DLLS because something doesn't make sense to me. 1. Are you explicitly setting the "timeout" values in the init_protocol calls? If so, what are you setting them to be? 2. Are you loading more than one instance of the DLLs or are all your examples structured in a "single-threaded" fashion? Based on these answers I will be able to provide better feedback. In addition, I would recommend that you update your rowers to use the current PM3 Beta firmware release which can be found on the Concept2 website (http://www.concept2.com/05/rower/servic ... update.asp). The versions you are using are quite old and many changes have taken place since their release. MarkL

[old] bbsportz · Post by **[old] bbsportz** » May 11th, 2005, 9:12 pm

<table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><div class='genmed'>QUOTE(mlyons @ May 12 2005, 12:09 AM)</div></td></tr><tr><td class='quote'>MarkL, "1. Are you explicitly setting the "timeout" values in the init_protocol calls? If so, what are you setting them to be?" Here are the calls to the PM3 from my Init function: tkcmdsetDDI_init(); _DDI_VersionNo = tkcmdsetDDI_get_dll_version(); tkcmdsetDDI_discover_pm3s(TKCMDSET_PM3_PRODUCT_NAME2, 0, &num_units); tkcmdsetCSAFE_init_protocol(100); csafeVerNo = tkcmdsetCSAFE_get_dll_version(); I cannot remember how I got around to placing the 100 in the CSAFE_init... The timeout in the function below is set to 70. tkcmdsetUSB_do_DDIcommand(port, cmd_data, rsp_data, timeout); I took this from an example in the manual (pg 36 rev0.09). I have no idea what the implications of the timeout values are. "2. Are you loading more than one instance of the DLLs or are all your examples structured in a "single-threaded" fashion?" I have a managed C# application calling functions in the C++ managed DLL. I have not explicitly added any threading mechanisms so I assume it is just running on the default application thread. "I would recommend that you update your rowers to use the current PM3 Beta firmware release ..... The versions you are using are quite old ...." What is the link between V95/V976 and Ver 88 Beta 8 ? I MarkA </td></tr></table>

[old] mlyons · Post by **[old] mlyons** » May 11th, 2005, 9:34 pm

MarkA, The timeouts for both the Csafe and DDI define how long the "blocking" DLL calls will wait for a response to the command string before returning a timeout error. A timeout value of "0" would return immediately without any timeout error. Retrying a command after getting a timeout error could be a problem if you set the timeout unnecessarily short (e.g., shorter than what the PM3 can actually achieve in practice). This would lead to "overwhelming" the PM3 command and response strings leading to error conditions displayed on the PM3, but should not result in resets/crashes. When you stated that you were polling at 50Hz I was suspicious because the PM3 cannot reply at a 50Hz. You may get an occasional response back in 20 msec., but on average its 30 - 50 msec.. So I'm not sure how you could be achieving a 50Hz poll. I'm not going to revert back to v95/976 (which are numerous bug fixes and improvements behind the current Beta release) to perform testing to duplicate your problems. It doen't make any sense for me to search for a bug that may have already been fixed. That's why I would like you to upgrade before continuing. I used the DemoAPI application provided w/ the SDK today using both the CSAFE command and DDI command features w/ the "repeat" feature selected and repeat period of 10 msec. This causes the commands to be sent as quickly as possible. I could not duplicate the behavior you described in your post. One point I did want to clarify was about handling the responses to the DDI call where you are using the raw CSAFE frame. Are you familiar with the "stuff byte" feature of CSAFE and are you handling that properly? If not, then your interpretation the DDI responses could be incorrect causing you to think you are seeing bad data being sent back by the PM3. MarkL

[old] bbsportz · Post by **[old] bbsportz** » May 11th, 2005, 11:10 pm

<table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><div class='genmed'>QUOTE(mlyons @ May 12 2005, 12:34 PM)</div></td></tr><tr><td class='quote'>MarkL, "The timeouts for both the Csafe and DDI define how long the "blocking" DLL calls will wait for a response to the command string before returning a timeout error." Now that makes sense. Thanks ____________________________________________ " .... This would lead to "overwhelming" the PM3 command and response strings leading to error conditions displayed on the PM3, but should not result in resets/crashes." According to what you have written above then "error condition displayed" is what I should have written instead of 'crashed'. Sorry about that. _____________________________________________________ "When you stated that you were polling at 50Hz I was suspicious because the PM3 cannot reply at a 50Hz. You may get an occasional response back in 20 msec., but on average its 30 - 50 msec.. So I'm not sure how you could be achieving a 50Hz poll." ____________________________________________________ "I'm not going to revert back to v95/976 ... It doen't make any sense for me to search for a bug that may have already been fixed. That's why I would like you to upgrade before continuing." I agree with you fully. I thought that the higher the V numbering the more recent the Version so I assumed that I was using the very latest drivers/software. Sorry for the misunderstanding. As soon as I read your previous posting I downloaded and updated one of the rowers. But I am still confused between V976/SDK and V88#5. When I ran the firmware installer it presented V088. Does that mean that V97x has rolled over to V0xx? The installer questioned me on whether I wanted to DOWNGRADE the firmware to V88 ? I said yes. If V88 Buildx is the the latest PM3 firmware. The I suppose V97x SDK is the latest in developer libraries with the exception of the firmware that comes with it. Is that right? "Are you familiar with the "stuff byte" feature of CSAFE and are you handling that properly?" I need to re-read that area and come back to you on it. I suspect I am not handling it properly. Thank you, MarkA </td></tr></table>

[old] mlyons · Post by **[old] mlyons** » May 12th, 2005, 5:46 am

<table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><div class='genmed'>QUOTE(bbsportz @ May 11 2005, 10:10 PM)</div></td></tr><tr><td class='quote'><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><div class='genmed'>QUOTE(mlyons @ May 12 2005, 12:34 PM)</div></td></tr><tr><td class='quote'>MarkL, "The timeouts for both the Csafe and DDI define how long the "blocking" DLL calls will wait for a response to the command string before returning a timeout error." Now that makes sense. Thanks ____________________________________________ " .... This would lead to "overwhelming" the PM3 command and response strings leading to error conditions displayed on the PM3, but should not result in resets/crashes." According to what you have written above then "error condition displayed" is what I should have written instead of 'crashed'. Sorry about that. [Please include the error # displayed on the PM3 when you report the problem as it helps me to understand what might have happened] _____________________________________________________ "When you stated that you were polling at 50Hz I was suspicious because the PM3 cannot reply at a 50Hz. You may get an occasional response back in 20 msec., but on average its 30 - 50 msec.. So I'm not sure how you could be achieving a 50Hz poll." ____________________________________________________ "I'm not going to revert back to v95/976 ... It doen't make any sense for me to search for a bug that may have already been fixed. That's why I would like you to upgrade before continuing." I agree with you fully. I thought that the higher the V numbering the more recent the Version so I assumed that I was using the very latest drivers/software. Sorry for the misunderstanding. As soon as I read your previous posting I downloaded and updated one of the rowers. But I am still confused between V976/SDK and V88#5. When I ran the firmware installer it presented V088. Does that mean that V97x has rolled over to V0xx? [The 9xx version numbers is used for "internal" and "external" Alpha firmware before it gets to the Beta stage. In the case of the SDK, the public CSAFE functionalityy was newly introduced and not in the "production" firmware at all, so it was given an Alpha designation. The current PM3 production firmware is Rev 082 and when we release the Beta firmware to production it will be Rev 088] The installer questioned me on whether I wanted to DOWNGRADE the firmware to V88 ? I said yes. [The installer is designed primarly to handle production firmware installing, so the logic is there to warn people if they are inadvertently "downgrading" their firmware. In this situation you are going from Alpha firmware to Beta firmware so it doesn't apply. Yes was the correct answer.] If V88 Buildx is the the latest PM3 firmware. The I suppose V97x SDK is the latest in developer libraries with the exception of the firmware that comes with it. [The 97x was the most recent in the Alpah release of the SDK. Then we continued to make fixes and changes, along with significant testing internally before releasing the 88Beta. We are now up to Build 8 of Beta and will likely have several more Builds before it's final] Is that right? "Are you familiar with the "stuff byte" feature of CSAFE and are you handling that properly?" I need to re-read that area and come back to you on it. I suspect I am not handling it properly. Thank you, MarkA </td></tr></table> </td></tr></table>

[old] haboustak · Post by **[old] haboustak** » May 12th, 2005, 10:07 am

<table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><div class='genmed'>QUOTE(bbsportz @ May 10 2005, 11:18 PM)</div></td></tr><tr><td class='quote'>Problem 1: What is the limit on the polling period ? I can get to 20 milliseconds (50hertz) but anything quicker than that and the PM3 crashes. </td></tr></table> I think that your method of polling the PM3 is causing the errors. I've spent a day or two stumbling over the same thing myself. The do_command variants of the SDK are blocking - so if you're single threaded you technically cannot send the PM3 more data then it can process, because you can only send one command at a time. When your lone thread exits the SDK function you know the PM3 is ready for the next command. From your posts, it sounds like your intention is to poll the PM3 in the UI thread and that you only have one thread running in your app. You probably have an OnTimer() event handler that's responding to WM_TIMER messages in order to schedule regular processing intervals for the polling - or whatever the managed equivelant is on top of the platform SDK (perhaps a Timer object) The problem is that the PM3 SDK creates a message pump while it waits for a response from the PM3. If timer events come in faster than the PM3 can send and receive, your single thread starts to send data out of order. This can get worse when you also have events tied to event handlers for buttons and controls. If you play with fast timers (< ~15ms) and breakpoints in the timer loop, you should be able to construct a call stack that looks something like this: wndClass!OnTimer() <-- timer re-entry user32.dll!xxxxx() user32.dll!xxxxx() user32.dll!xxxxx() <-- PM3 message loop PM3USB.DLL!xxxxx() <-- PM3 delay PM3USB.DLL!xxxxx() <-- PM3 USB function PM3USB.DLL!xxxxx() <-- PM3 USB function PM3DDI.DLL!xxxxx() <-- PM3 DDI function PM3DDI.DLL!xxxxx() <-- PM3 DDI function wndClass!OnTimer() <-- timer initial entry user32.dll!xxxxx() user32.dll!xxxxx() user32.dll!xxxxx() <-- wndClass message loop (DISCLAIMER: this is what a non-managed call stack might look like) To the PM3, this looks like: [send 1] [send 2] (error) [recv 2] [recv 1] The good news is that the PM3 SDK should be thread-safe. So if instead of polling using a timer you do the polling in a seperate thread - you won't have any problems. Threads don't rely on message queues and so the PM3 SDK won't cause re-entry. Better still, the SDK will also manage requests from your two threads (UI and Polling) and make sure they happen in-order. You can then eliminate any calls that are timing dependant (dropping DDI requests, waiting 20ms, etc). Another, potentially less disruptive way of doing this is to use a single-shot timer (if one is available). At the end of your polling code you would set another single-shot timer. This way Windows doesn't queue up any WM_TIMER messages while you're waiting on I/O from the PM3. This doesn't solve the issue of re-entry caused by Button event handlers and Timer event handlers though. Mike

[old] bbsportz · Post by **[old] bbsportz** » May 12th, 2005, 11:41 pm

To: Mark Lyons and Mike haboustak, Thanks for the replys. It has clearly helped me sort out all my issues. I was using a threaded Timer object and at times it was definitely re-entrying before the PM3 was ready. I have also moved back to the CSafe function for the PM3 Specific calls to get away from the byte stuffing. Mike, your point about "... polling in a seperate thread...". Thanks for that tip I will give it a go in a few weeks. All seems well. I am done with this post. Thanks again Cheers MarkA