PM3 - 161 error

Post questions and issues with Concept2 PM3 SDK

PM3 - 161 error

Postby MarkD » February 5th, 2015, 4:47 pm

Hi,

When interfacing with the PM3, I occasionally get a 161 code on the screen and a read timeout return code. These occur at different times. I have built an erg simulator which drives the input to two PMs with exactly the same signal. Each PM may or may not give a 161 error anything from 2 minutes to 2 hours into the "workout" so this appears to be a glitch and not a consistent transaction error.

For those who have done a lot of PM3 programming, are there some "gotchas" to avoid? I am doing my best to keep the frequency of transactions as low as possible and below the specified limits. What else have you come across that might be causing random read timeouts?

Thanks, Mark.
MarkD
Paddler
 
Posts: 5
Joined: December 7th, 2014, 8:02 pm
Location: Sammamish, WA or Reading, UK

Re: PM3 - 161 error

Postby MarkD » February 8th, 2015, 3:55 am

An update - I set the protocol timeout to be tighter than default (now 200ms, was 1000ms).

This may have proved that the two errors (161 and USB Read Timeout) are related as the time between the 161 error and the read-timeout error follows the timeout I just set.

161 is checksum error. I am only ever sending CSAFE commands so the checksum is generated by the CSAFE DLLs. I assume that is why I get the read timeout - the PM never processes the bad command it received so does not return data.

Is it common to get corrupted packets? These errors are fairly regular - maybe as short as 2 minutes but often occur 20, 30 or 40 minutes into the test.

My work-around was
    Turn off screen errors
    ignore read timeouts,
    clean up code that was expecting a result
    read the screen error through the api to clear the latched PM error

Thanks, Mark.
MarkD
Paddler
 
Posts: 5
Joined: December 7th, 2014, 8:02 pm
Location: Sammamish, WA or Reading, UK

Re: PM3 - 161 error

Postby MarkD » February 12th, 2015, 7:06 pm

ok, I finally fixed this. It turns out that the csafe DLL isn't quite thread-safe.

The fix was to lock the entry to CSafe_Command. Here is some C# below if you need it. The wrapper code allows one thread at a time to enter the ...command() function.

Obviously, best to set the protocol_init(timeout) value to as small as you can without introducing timeout errors. I am running with 300ms timeouts ok and will start testing where the break down limit is. Also need to check what happens when I unplug PM - do the others get blocked? Will test.

Code: Select all
        /// <summary>
        /// Sends a CSAFE command to a PM device and returns the response data.  Note: the unit address is determined using the DiscoverPM function in the PM3DDI DLL.
        /// </summary>
        /// <remarks>Original: PM3CSAFE_API ERRCODE_T tkcmdsetCSAFE_command(UINT16_T unit_address,UINT16_T cmd_data_size, UINT32_T cmd_data[], UINT16_T *rsp_data_size, UINT32_T rsp_data[]);</remarks>
        /// <param name="unit_address">Address of PM device</param>
        /// <param name="cmd_data_size">Size of cmd data</param>
        /// <param name="cmd_data">Command data</param>
        /// <param name="rsp_data_size">Size of rsp data</param>
        /// <param name="rsp_data">Response data</param>
        /// <returns>Zero if successful, Error code otherwise</returns>
        [DllImport("ExternalDlls\\PM3CsafeCP.dll", CallingConvention = CallingConvention.Cdecl, EntryPoint = "?tkcmdsetCSAFE_command@@YAFGGQAKPAG0@Z")]
        public static extern ushort tkcmdsetCSAFE_command(
           [In] ushort unit_address,
           [In] ushort cmd_data_size,
           [In] uint[] cmd_data,
           [In, Out] ref ushort rsp_data_size,
           [In] uint[] rsp_data);

        private static object tkcmdsetCSAFELock = new Object();
        public static ushort tkcmdsetCSAFE_command_lock(
           ushort unit_address,
           ushort cmd_data_size,
           uint[] cmd_data,
           ref ushort rsp_data_size,
           uint[] rsp_data)
        {
            ushort ecode;
            lock (tkcmdsetCSAFELock)
            {
                ecode = tkcmdsetCSAFE_command(unit_address, cmd_data_size, cmd_data, ref rsp_data_size, rsp_data);
            }
            return (ecode);

        }


Hope this helps. also hope a revision to the DLLs will come soon. Perhaps open source so we can look at and improve it? nudge nudge...
MarkD
Paddler
 
Posts: 5
Joined: December 7th, 2014, 8:02 pm
Location: Sammamish, WA or Reading, UK


Return to SDK Questions

Who is online

Users browsing this forum: No registered users and 1 guest