• AVR Freaks

Hot!RTDM problem for reading dynamic data

Author
Perpetum
New Member
  • Total Posts : 10
  • Reward points : 0
  • Joined: 2020/11/29 15:50:17
  • Location: 0
  • Status: offline
2021/01/08 21:13:49 (permalink)
0

RTDM problem for reading dynamic data

Hi forum,
I am spinning a BLDC motor using AN957 base code and I have added RTDM support. My goal is to monitor motor variables in real time (slow e.g. 10 times/sec).  I've written a LabVIEW based RTDM protocol VI to basically replace DMCI to be MPLAB independent.  Everything works fine, I can test the link, write variables and read "static" variables.  By static variables I mean variables that the dsPIC33 is not writing to.  Clearly, to monitor motor parameters/variables I need to continuously send a read request message continuously.  I am doing that every 100msec.
 
The problem I am facing is most likely contention between the UART interrupt and the motor control main loop where I snapshot the variables. When contention happens the RTDM response to the read request gets messed up and LabVIEW receives the incorrect number of bytes.  
 
Can anyone recommend a way to interlock the UART interrupt and the variables snapshot?  I did try a setting lock flag in the UART interrupt and then use it to conditionally snapshot the variable but it did not work.  the RTDM response is still messed up after a while (sometimes 100s -1000s responses)
 
Thanks,
Perpetum
#1

16 Replies Related Threads

    atonyb
    Starting Member
    • Total Posts : 46
    • Reward points : 0
    • Joined: 2014/05/08 07:11:07
    • Location: 0
    • Status: offline
    Re: RTDM problem for reading dynamic data 2021/01/11 08:36:22 (permalink)
    0
    I'm not sure I totally understand your problem - but perhaps, depending on the execution rate of the main control loop (and therefore whether or not such latency would be tolerable), you could just set a flag when making a request which is read at the end of the next execution of the control loop to trigger the reply. That way it might guarantee a maximal amount of time to service the data transfer and avoid any contention?
     
    That, or just prioritised interrupts or something....
    #2
    T Yorky
    Super (Thick) Member
    • Total Posts : 580
    • Reward points : 0
    • Joined: 2012/08/28 02:07:35
    • Location: UK
    • Status: offline
    Re: RTDM problem for reading dynamic data 2021/01/11 14:27:23 (permalink)
    0
    You may find this useful...
     
    www.microchip.com/forums/m737182.aspx
    #3
    Perpetum
    New Member
    • Total Posts : 10
    • Reward points : 0
    • Joined: 2020/11/29 15:50:17
    • Location: 0
    • Status: offline
    Re: RTDM problem for reading dynamic data 2021/01/11 18:56:48 (permalink)
    0
    Wow, I take my hat off T Yorky!  I think you nailed it down.  I carefully read your entire thread and I believe I am facing the very same issue.  I am eager to get it to test. Hopefully tonight.  BTW, just last night I was reading about the X2C Scope 3rd party plugin from Linz Mechatronics which is a professionally done version of the RTDM protocol plus their entire Scilab/Xcos based framework.  They use the LNet (https://x2c.lcm.at/downloads) protocol which in essence is very similar to the RTDM one but they addressed the delimiter-within-data/address by adding a FILL BYTE (0x0) if the delimiter if found within the address/data.  Thanks again, I will update the forum after my testing.
     
    Perpetum 
    #4
    Perpetum
    New Member
    • Total Posts : 10
    • Reward points : 0
    • Joined: 2020/11/29 15:50:17
    • Location: 0
    • Status: offline
    Re: RTDM problem for reading dynamic data 2021/01/11 20:30:00 (permalink)
    0
    Hi T Yorky,
     
    Reporting back... I carefully followed the steps in your www.microchip.com/forums/m737182.aspx post. Replaced the 4 files by yours including your latest 593_RTDM.o.  Unfortunately, XC16 (version 1.61) does not like the format of this object and the build fails (see awfully long dump below sorry). I am using dsPIC33FJ32MC204, could it be that your object is for a different family? 
    Any help would be greatly appreciated (even less optimized C code :)).
     
    Thanks,
    Perpetum
     
    make -f nbproject/Makefile-default.mk SUBPROJECTS= .build-conf
    make[1]: Entering directory 'D:/bici/microchip/AN957_dsPIC33FJ32MC204_MCLV/AN957-BLDC.X'
    make -f nbproject/Makefile-default.mk dist/default/production/AN957-BLDC.X.production.hex
    make[2]: Entering directory 'D:/bici/microchip/AN957_dsPIC33FJ32MC204_MCLV/AN957-BLDC.X'
    "C:\Program Files\Microchip\xc16\v1.61\bin\xc16-gcc.exe" ../Init.c -o build/default/production/_ext/1472/Init.o -c -mcpu=33FJ32MC204 -MMD -MF "build/default/production/_ext/1472/Init.o.d" -g -omf=elf -DXPRJ_default=default -no-legacy-libc -O0 -I".." -I"." -I"C:/Program Files (x86)/Microchip/MPLAB C30/support/peripheral_30F_24H_33F" -I"C:/Program Files (x86)/Microchip/MPLAB C30/support/dsPIC33F/h" -I"C:/Program Files (x86)/Microchip/MPLAB C30/support/dsPIC33F" -msmart-io=1 -Wall -msfr-warn=off -mdfp="C:/Users/Fabian/.mchp_packs/Microchip/dsPIC33F-GP-MC_DFP/1.3.64/xc16"
    "C:\Program Files\Microchip\xc16\v1.61\bin\xc16-gcc.exe" ../Interrupts.c -o build/default/production/_ext/1472/Interrupts.o -c -mcpu=33FJ32MC204 -MMD -MF "build/default/production/_ext/1472/Interrupts.o.d" -g -omf=elf -DXPRJ_default=default -no-legacy-libc -O0 -I".." -I"." -I"C:/Program Files (x86)/Microchip/MPLAB C30/support/peripheral_30F_24H_33F" -I"C:/Program Files (x86)/Microchip/MPLAB C30/support/dsPIC33F/h" -I"C:/Program Files (x86)/Microchip/MPLAB C30/support/dsPIC33F" -msmart-io=1 -Wall -msfr-warn=off -mdfp="C:/Users/Fabian/.mchp_packs/Microchip/dsPIC33F-GP-MC_DFP/1.3.64/xc16"
    "C:\Program Files\Microchip\xc16\v1.61\bin\xc16-gcc.exe" ../SensoredBLDC.c -o build/default/production/_ext/1472/SensoredBLDC.o -c -mcpu=33FJ32MC204 -MMD -MF "build/default/production/_ext/1472/SensoredBLDC.o.d" -g -omf=elf -DXPRJ_default=default -no-legacy-libc -O0 -I".." -I"." -I"C:/Program Files (x86)/Microchip/MPLAB C30/support/peripheral_30F_24H_33F" -I"C:/Program Files (x86)/Microchip/MPLAB C30/support/dsPIC33F/h" -I"C:/Program Files (x86)/Microchip/MPLAB C30/support/dsPIC33F" -msmart-io=1 -Wall -msfr-warn=off -mdfp="C:/Users/Fabian/.mchp_packs/Microchip/dsPIC33F-GP-MC_DFP/1.3.64/xc16"
    "C:\Program Files\Microchip\xc16\v1.61\bin\xc16-gcc.exe" ../../TYorky/090_RTDM.c -o build/default/production/_ext/1778914250/090_RTDM.o -c -mcpu=33FJ32MC204 -MMD -MF "build/default/production/_ext/1778914250/090_RTDM.o.d" -g -omf=elf -DXPRJ_default=default -no-legacy-libc -O0 -I".." -I"." -I"C:/Program Files (x86)/Microchip/MPLAB C30/support/peripheral_30F_24H_33F" -I"C:/Program Files (x86)/Microchip/MPLAB C30/support/dsPIC33F/h" -I"C:/Program Files (x86)/Microchip/MPLAB C30/support/dsPIC33F" -msmart-io=1 -Wall -msfr-warn=off -mdfp="C:/Users/Fabian/.mchp_packs/Microchip/dsPIC33F-GP-MC_DFP/1.3.64/xc16"
    "C:\Program Files\Microchip\xc16\v1.61\bin\xc16-gcc.exe" -o dist/default/production/AN957-BLDC.X.production.elf build/default/production/_ext/1472/Init.o build/default/production/_ext/1472/Interrupts.o build/default/production/_ext/1472/SensoredBLDC.o build/default/production/_ext/1778914250/090_RTDM.o ..\..\TYorky\593_RTDM.o -mcpu=33FJ32MC204 -omf=elf -DXPRJ_default=default -no-legacy-libc -Wl,,,--defsym=__MPLAB_BUILD=1,,--script=p33FJ32MC204.gld,--stack=16,--check-sections,--data-init,--pack-data,--handles,--isr,--no-gc-sections,--fill-upper=0,--stackguard=16,--library-path="..",--library-path=".",--library-path="C:/Program Files (x86)/Microchip/MPLAB C30/lib/dsPIC33F",--no-force-link,--smart-io,-Map="dist/default/production/AN957-BLDC.X.production.map",--report-mem,--memorysummary,dist/default/production/memoryfile.xml -mdfp="C:/Users/Fabian/.mchp_packs/Microchip/dsPIC33F-GP-MC_DFP/1.3.64/xc16"
    ..\..\TYorky\593_RTDM.o: file not recognized: File format not recognized
    #5
    Perpetum
    New Member
    • Total Posts : 10
    • Reward points : 0
    • Joined: 2020/11/29 15:50:17
    • Location: 0
    • Status: offline
    Re: RTDM problem for reading dynamic data 2021/01/11 20:41:30 (permalink)
    0
    Hi T Yorky again,
     
    If I remove the 593_RTDM.o object from the build, these are the two missing functions
    : undefined reference to `_RTDM_ResetCRC'
    : undefined reference to `_RTDM_MB_Crc16WithReset'
     
    Any help would be greatly appreciated (even less optimized C code :)).
     
    Thanks,
    Perpetum
     
    #6
    T Yorky
    Super (Thick) Member
    • Total Posts : 580
    • Reward points : 0
    • Joined: 2012/08/28 02:07:35
    • Location: UK
    • Status: offline
    Re: RTDM problem for reading dynamic data 2021/01/12 04:52:36 (permalink)
    0
    The link I gave has a dialogue with cstook towards the end. The solution is there. The post is orig from 2013. MplabX changed its obj format from Mplab C30 format.
    Try the link to rics forum for a debug facility that I still use today for pic33 projects. Updated now but this ver still very useful.
    Placing 'escape sequences' in protocols is a common solution to an age old problem.
    Note the RTDM does not use magic numbers. This is another failing which I have seen create problems. The aim was to keep backward compat with the development software. Hindsight has shown this to be fruitless exercise.
    MChip never corrected the problem (they created) in their dev environment end.
    T Yorky.
    #7
    Perpetum
    New Member
    • Total Posts : 10
    • Reward points : 0
    • Joined: 2020/11/29 15:50:17
    • Location: 0
    • Status: offline
    Re: RTDM problem for reading dynamic data 2021/01/12 20:59:14 (permalink)
    0
    Hi TYorky,
    Reporting back... Day 2: I read again the thread with cstook and was able to integrate and build your routines.  Everything seems to be working fine.  I can do a link sanity check, read and write variables.
    However..
    I am getting the same byte misalignment when LabVIEW sends back to back read requests. I am expecting a 7 byte response but from time to time I receive 8 bytes where the binary codes are shifted right by one byte.  for example, a good response is 2B24 5B3F 232B 0C = +$dd#cc and a bad one is BD2B 240B 4123 0A=?+$dd#c (missing last CRC byte because labview stopped. I think I am seeing the same problem you corrected at the target end in the PC side (my labview code).  
    I wanted to try your PC side app PICCADA to make sure that is the case but when I downloaded TinyGlue to assemble the bit and pieces Norton flagged it as infected with WS.Reputation.1 and I stopped.  Could you by any chance share it via a different route? (email?)
    Also, at the high level, could you help me understand what mods did you do to parse the message in a more robust way to avoid +, $, or # in the data/address?
    Thanks again,
    Perpetum
    #8
    T Yorky
    Super (Thick) Member
    • Total Posts : 580
    • Reward points : 0
    • Joined: 2012/08/28 02:07:35
    • Location: UK
    • Status: offline
    Re: RTDM problem for reading dynamic data 2021/01/13 15:33:31 (permalink)
    4 (1)
    Can not comment on your virus scanner. I guess that it is complaining that it is not 'signed'. This is common for downloads from github and forums. Does not matter where you download from it will complain. That is a choice you make. I normally publish the size to stop people adding sh1t to stuff. Piccada was targeted as a type of SCADA if you are familiar. It is a really good debugging aid that allows access to global variables in the map. After importing the map, the variable can be selected and viewed/adjusted dynamically. There is also a Virtual LCD window that allows you to write ASCII text into an array buffer and it appears in a window in Piccada. Use this for Error descriptions etc.
    I write my utilities in a fashion similar to the old DOS COM files. Everything combined into a single EXE, no DLL. They do not need installing and can be executed in any folder. If required by the utility a INI file is created which is in ASCII. Numerous copies can be any where on your disk each with their own INI. I tend to have a copy of PICCADA in each project file which is customised for that project. No selecting config files on start up. Just double click the EXE in the project folder and that copy is dedicated to that PIC project.
    The parse mods are in the rx interrupt. Instead of the usual 'message trapping between delimiters' it is neccessary to do a bit of parsing as the characters come in. If the msg has fields that could contain the delimiter the valid position of the delimiter is determined and only allowed according to the msg type and (expected) length.
    T Yorky.
    #9
    Perpetum
    New Member
    • Total Posts : 10
    • Reward points : 0
    • Joined: 2020/11/29 15:50:17
    • Location: 0
    • Status: offline
    Re: RTDM problem for reading dynamic data 2021/01/13 20:19:15 (permalink)
    0
    Hi T Yorky,
    I ventured to overrule the virus scanner and was able to unzip and run tinyglue to reassemble cutitup and finally unzip it. Reassemble piccada, unzip it and can run it now!
    Thank you for the parse mods tips.  I looked at your rx interrupt routine and I am trying to use similar logic in my LabVIEW program.
    Thanks a lot for your help so far!
    Perpetum
    post edited by Perpetum - 2021/01/13 20:51:22
    #10
    Perpetum
    New Member
    • Total Posts : 10
    • Reward points : 0
    • Joined: 2020/11/29 15:50:17
    • Location: 0
    • Status: offline
    Re: RTDM problem for reading dynamic data 2021/01/13 20:24:50 (permalink)
    0
    T Yorky,
    UI looks nice, I am getting familiar with all the options but I am having trouble with the MAP file.  My project is MPLAB X (dotx project) and it seems that PIC project selection is hardcoded to MPLAB 8 (dotmcp). Any advice?
    Thanks,
    Perpetum
     
    post edited by Perpetum - 2021/01/13 20:52:50
    #11
    T Yorky
    Super (Thick) Member
    • Total Posts : 580
    • Reward points : 0
    • Joined: 2012/08/28 02:07:35
    • Location: UK
    • Status: offline
    Re: RTDM problem for reading dynamic data 2021/01/14 05:47:42 (permalink)
    0
    From your last post I presume you have managed to reconstruct and run piccada.exe .
    For years I have been meaning to do a help file. Still not happened. So a quick start tutorial.
    First rule is Piccada tries to be retentive. That is it restarts as it was closed down. This is achieved with piccada.ini , which is good old fashioned ascii file still supported by msoft. If you delete the piccada ini it will reset and just create a new blank ini on start up. So if you make copies for different pic projects just copy the exe into the folder and a new ini is produced when first started. The ini stores the complete path names, no relative paths. This is very important.
    It was originally designed in delphi 1 then expanded in C++. So some dialogues look old and were for a mitsubishi processor! Apologies.
    It starts with the dashboard (which can be minimised). Numerous buttons. First to use is Application Name <Select>. I have used the term 'faceplate' for this. It basically gives this configuration/set up a name and a folder to store it in. Any changes/settings are stored here ON SHUTDOWN (V important). And numerous Faceplates can be selected to do different unit testing. The last selected faceplate will be reloaded on start up.
    The next important button is <MPLab Update>. Brings up window with status and three buttons to right. Top button is select project. This is actually the map file. With MPLab 8 the map is generally stored with the mcp and c files. With MPlabX you have to delve into the project folder structure. The map is contained in the DIST/DEFAULT/PRODUCTION folder. As said before, the full path is stored and should only need setting once. Exception for labx in that there is a different map for picket debug mode. After selecting <Convert> the line should go green for success. the map has been read in. The <Update> allows the existing config addresses to be updated as you compile and change the memory map. Hide when complete. I think the <Configure Port> is self explanatory.
    <Point Inspector> is the most useful. The dialogue provides up to 50 points to monitor/control. Never use pts 0..9 for general use. They have pre allocated uses.
    Setup a point. Choose number 10. Start from top. Name can be entered or if a map is imported (earlier) selected in the drop down. If selected the address from the map will be filled out for you. Ignore Type and Flags. Select the variable type char etc. Select scan 3. Select Read/Write. Ignore the Scaling. In Point Data Acquisition select RTDM Node. Assuming all is OK. Select Go Online from the dashboard (indicator goes green) and you will see the Point 10 update. There is a simple count to show success. You can edit change the scaled value and it will write to the PIC.
    Simple but very useful.
    T Yorky.
     
     
    #12
    T Yorky
    Super (Thick) Member
    • Total Posts : 580
    • Reward points : 0
    • Joined: 2012/08/28 02:07:35
    • Location: UK
    • Status: offline
    Re: RTDM problem for reading dynamic data 2021/01/14 05:52:48 (permalink)
    0
    Forgot to mention, when entering point names these must match the GLOBAL variable name exactly (Case) AND have an underscore as in the Map file (most common error). So if you cut and past from the C code, remember to add the underscore. No access to structures. Too much work. Will detail some other bits later.
    #13
    Perpetum
    New Member
    • Total Posts : 10
    • Reward points : 0
    • Joined: 2020/11/29 15:50:17
    • Location: 0
    • Status: offline
    Re: RTDM problem for reading dynamic data 2021/01/14 17:33:21 (permalink)
    0
    Thank you TYorky, Piccada is working like a charm!  Unfortunately, I must have a bug somewhere in my target app because I am seeing the same byte misalignment from time to time as with my Labview program.  Debug continues...
     
    Does piccada signal somewhere that the target sent a bad message?  I see Msg Read Index is most of the time =-1 but sometimes =1.  Also, the Msg Monitor counts up but sometimes skips a count.  Is this expected?
    #14
    Perpetum
    New Member
    • Total Posts : 10
    • Reward points : 0
    • Joined: 2020/11/29 15:50:17
    • Location: 0
    • Status: offline
    Re: RTDM problem for reading dynamic data 2021/01/14 17:52:31 (permalink)
    0
    BTW, 

    The application I am using is AN957 (sensored BLDC motor control) and I integrated the RTDM code.  AN957 is a very simple application, it uses IC1, IC2, IC7, and ADC1 interrupts for the bare bone BLDC commutation.  I am pretty sure you probably know it inside out. These are all default priority to level 4. There is also a Timer1 interrupt set to trigger at a very low rate of 1kHz to service the closed loop PID.   I set this interrupt priority to level 1. UART RX ISR is level 3.
     
    The only thing that can interrupt the UART are the IC1, IC2, IC7, and ADC1 interrupts which are level 4.  Could I be getting corruption during a nested interrupt sequence.  I am not taking any special care for this.  Should I? The variables that I am interested in reading get updated in both the ADC1 int and Timer1 int.
     
    Thanks again,
    Perpetum
     
    #15
    Perpetum
    New Member
    • Total Posts : 10
    • Reward points : 0
    • Joined: 2020/11/29 15:50:17
    • Location: 0
    • Status: offline
    Re: RTDM problem for reading dynamic data 2021/01/14 18:43:30 (permalink)
    0
    My Labview program is sending back to back read request messages to the target.  The 11 byte read request looks like this {24 6D A2 08 00 00 02 00 23 04 DB} = {$m, address=A208 0000, #bytes=0200, #, CRC}.  I expect a 7 byte response back from the target like this {+$, data=xx xx, #, CRC} = {2B 24 d d 23 c c}.  A log of the problem captured by labview is below
    ...
    2B 24 85 0B 23 5D F6
    2B 24 A4 01 23 0B 5C
    2B 24 A4 01 23 0B 5C
    2B 24 24 01 23 0A  <-- delimiter in data, message contains 6 bytes
    B4 2B 24 24 01 23 0A <-- 7 bytes but message is shifted right by one byte
    ...
    B4 2B 24 24 01 23 0A
    B4 2B 24 53 08 23 BC FE <-- 8 bytes message, delimiter no longer in data 
    2B 24 53 08 23 BC FE <-- 7 bytes message back in sync
    Any ideas how to fix this?
     
    #16
    T Yorky
    Super (Thick) Member
    • Total Posts : 580
    • Reward points : 0
    • Joined: 2012/08/28 02:07:35
    • Location: UK
    • Status: offline
    Re: RTDM problem for reading dynamic data 2021/01/15 09:44:42 (permalink)
    0
    Are your results from a logic analyser/sniffer? There is a 'service' that needs scanning (polling) on a regular basis. This is the RTDM_ProcessMsgs() from what you have described this would best be placed in the 1ms timer interrupt. A 1ms scan is ideal. As stated in the linked post if there is nothing to do then it just returns. I would suggest sticking to 38400. This allows the Tx to return a message without any delays between chars at 1msec scan.
     
    I suspect your problem is your Labview. The code posted has been used for years and is very robust if you stick to the scanning rules. The -1 to 1 change is associated with the 'posting' of Windows messages. A separate win task/thread handles comms. This is posted message jobs. -1 is no job outstanding. a positive number is its job no. If you have numerous points you will see the number be different to 1.
    Yes the number can jump more than 1 and is dependent on the comms traffic. There is a fast mode for one of the features for gathering logged data and saving to CSV file. The comms operates faster than the screen update.
     
    Attached is a screen capture of the configurable point monitor. As you can see if you have numerous points they can be displayed as a dashboard. With data entry points for settings (blue text instead of green). The point inspector allows the raw Pic data to be scaled into eng units. The point monitor allows these units to be shown on the screen. There is a 'multi state' indicator that allows a 'state description' to be displayed depending on the PIC variable value. In the capture example you will see the buttons at the bottom can be configured to perform actions in the code or debug steps its up to the user.
     
    T Yorky
    post edited by T Yorky - 2021/01/15 09:48:57

    Attached Image(s)

    #17
    Jump to:
    © 2021 APG vNext Commercial Version 4.5