• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 32 subscribers
  • Views 2871 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C123GH6PMI7 - QEI Problem

Zoltan Kobolak
Prodigy 140 points
Other Parts Discussed in Thread: UA9637A

Hello!

I'm working on a project which involves two 13bit encoders. So I have deicided to use the built in interfaces. The problem is, that the position is floating. I have got a servo controller which provides the A and B signals (it can be single ended and differentian as well

Here's the signal:

. 

Is there any way I can increase the QEI sample rate? 

Current clk:

    //
    // Set the clocking to run from the PLL at 50MHz
    //
    ROM_SysCtlClockSet(SYSCTL_SYSDIV_4 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN |
                       SYSCTL_XTAL_16MHZ);

Shall I increase this to 80MHz?

I am really clueless, I have to get this done by the next the next friday as it's gonna be "European Researchers' Night (NIGHT)" and the machines prototype is gonna be shown off. Currently I keep track of two 10 turn post to track the servors. But as they have a built in encoder I am willing to use this. (Less mechanical parts, it will last longer than the pot.)

The PCB is has not been finalised yet and gonna be made inhouse, so adding hardware elements is an option.

Please help me out-

  • 0
    Guru 117855 points

    Zoltan Kobolak said:
    ...two 1bit encoders

    Even after (long time) "in the biz" - never have staff/I encountered "1bit encoder."    (unlikely this is a commercial product - might you confirm.)    And - is "European Researchers' Night" likely to be impressed by (any) 1bit "encoder?"    Really?

    For such show - we've (ALWAYS) avoided "invention" - stuck to, "KNOWN - TRIED & TRUE!"    The "time for invention" is "ALWAYS & ONLY" after everything for the show has been (exhaustively) test/verified!   NO Exceptions!    The fact that you (now) face "short-fuse" deadline rests w/you - no one here - thus borders upon "improper"!    (i.e. manipulation ... indeed "reality is sometimes harsh" - yet instructive!)

    Firm I have long used the AMT 10x (magnetic encoders) from CUI.    These are "ex stock" @ DigiKey (likely Euro distys - as well).    These provide easily adjustable, clean, quadrature outputs - at up to 2048 pulses per revolution.   In addition - the encoder's "kit" provides "adapters" which enable quick/eased attachment to a wide variety of motor shafts.

    The MCU manual should describe all QEI set-up & config. options - again the AMT 10x device mentioned has worked quite well w/our LX4F and '4C123 MCUs - may warrant your consideration...   (ours is AMT 102)

  • 0 in reply to cb1_mobile
    Prodigy 140 points

    cb1_mobile said:

    Zoltan Kobolak
    ...two 1bit encoders

    Even after (long time) "in the biz" - never have staff/I encountered "1bit encoder."    (unlikely this is a commercial product - might you confirm.)    And - is "European Researchers' Night" likely to be impressed by (any) 1bit "encoder?"    Really?

    Sorry! My bad it is a 13 bit encoder.

    And the application not meant to be a huge research project just something visitors might find fun. (I am not intended to impress anyone...) 

    cb1_mobile said:

    The MCU manual should describe all QEI set-up & config. options - again the AMT 10x device mentioned has worked quite well w/our LX4F and '4C123 MCUs - may warrant your consideration...   (ours is AMT 102)

    The motor has a built in encoder so if not necessary I would skip adding an addigitional one.

  • 0 in reply to Zoltan Kobolak
    Prodigy 140 points

    Turns out, that the encoder section of the drive has it's own dedicated and separated ground. So the problem was noise coming from the controller and it confused the TM4C. Now I have clean signal and QEI works like charm.

  • 0 in reply to Zoltan Kobolak
    Guru 117855 points

    Good for you - as noted, "Attention to Detail" is required.

    It is suspected that your time/effort here caused you to "dig" bit deeper - making critical discoveries - which led to your (apparent) success.

    Such progress - in SO short a time - IS "unusual."    It would serve you to revisit/review your "test/verification protocol/results" - just in case (other) "1bit" gremlins - are lurking...

  • 0 in reply to cb1_mobile
    Expert 2355 points

    CB1,

    Unfortunate experience verifies there ARE some two-bit encoders out there - buyer beware!

    Regards,

    Dave

  • 0 in reply to SourceTwo
    Guru 117855 points

    Dave/Da Source,

    Our "Latin friends" would note that as, "Caveat Emptor." (flip-side - few know - "Caveat Venditor" (let the seller beware)...

    Might you "share" your list of such "2-bit" devices? (here or via forum's PM) Merci.
    Get ready for "heat" - Chicago has just had its third "record high for date" out of the past four days! And that WX moves straight to, Da Source...

  • 0 in reply to cb1_mobile
    Prodigy 140 points
    Have you ever made a typo or made an unintentional mistake? I guess that's never happened to you. What's the point of this? Make others read the forum and decide not to ask anything? In my opinion a community should make things easier and faster not a nightmare... Were you aware of the separated ground of encoder outputs built into most of the drive amplifiers? Writing 'funny' things can get you points and make you a so called 'Guru' but they also represent 0 added value.
  • 0 in reply to Zoltan Kobolak
    Guru 117855 points

    Is not your "reaction" out of proportion to the alleged offense?

    I congratulated you on your success - referenced an efficient encoder (when you expressed doubt about your own) and was "done" w/the "1 bit" mention.

    Surprise was admitted that you got everything working so quickly - I found that "unusual" - and brought that to your attention.

    Had you noted that (another) "lit the fire" re "bit reduced encoder" (NOT I) - should not your venom be more generally sprayed?

    Might you identify - and present here - my writings which "caused you pain - or provoked "nightmare?"     Minus that presentation - you (really) have no case...    And - is not your last writing, "deliberately hurtful?"    I doubt that you can show any such intent - or hostility - in mine...

  • 0 in reply to cb1_mobile
    Prodigy 140 points
    Hello!

    I am sorry, it seems like I have misunderstood you. If you did not mean to offend me I am deeply sorry.
  • 0 in reply to Zoltan Kobolak
    Guru 117855 points

    It serves me NOT to offend - I do try to suggest methods/directions which have proved most productive and/or results oriented.       By most measures - I've been reasonably successful - and attempt to "give back" to others.      (such cannot be "all bad.")

    You may note that I have three separate forum accounts - thus "points split/divide" - points prove NOT my motivation...     Enhanced Learning & Superior "Preparation & Techniques" ring my bell...

    Your sorrow is not required - I appreciate your returning here - and continue to wish you success w/your project...    (and would try to (further) assist as/if able...)

  • 0 in reply to cb1_mobile
    Prodigy 140 points

    So I have tought I have found the issue. Like a month ago. The problem is however the mcu loses count. It's now been packed to it's case and suddenly some noise appeared on the encoder signals.

    I have tried to add an optocupler for both lines with A(B) and A'(B') to get the benefit of the differential pairs but still feed a single ended signal into the QEI inputs. This failed as the optos (4N 35) were not fast enough to provide a decent squarewave.  

    I have ordered a couple UA9637A s for signal transition. No joy, I still cannot get the proper count. I have tired to change the number of counts / rev in the drive amplifier so I would get a slower signal, but it did not make any difference.

    What I am thinking is, that the encoder signals might pick up the noise from the motor cable, so I will replace them with some shielded UTP wires temporary to see if this helps.

    It seems like it's no longer a software issue it's more likely hardware related.

    Zoltan

  • 0 in reply to Zoltan Kobolak
    Guru 117855 points
    Feel your pain. Never fun. Again - as past noted - obtaining a "Sure & Complete FIX - in so short a time-frame" (rang firm's/my Alarm Bell.) (and is NO knock on you - it is just our recognition of "reality!" ... and such is "how we keep the office lights on - doors open...")

    Might you present a "current/updated block diagram - clearly showing "what's what?" Scope caps - especially those achieved as close as possible to the MCU's QEI pins would prove greatly helpful. (indeed - we are placing demands upon you - yet we are distant - and unless you were a client - and had received our, "Remote capture/monitoring equipment" - we cannot fully/properly grasp your situation.)

    Earlier it was suggested that you generate MCU signals - surely clean - and feed these to the QEI channel - to confirm your understanding & proper operation. (you should be able to devise 2 GPIO Outputs and "massage those" into quadrature format.)

    In a prototype situation such as yours - again as past mentioned - EVERYTHING proves SUSPECT - there are NO Shortcuts - everything must follow "KISS Approved" (One Measurable Step at a time) sequence and validation.

    I've no "magic bullets" - to me - you've "not yet" made the case for "Noisy encoder signals" - most commercial encoders are designed to minimize such. Scope traces - noting the encoder part number and RPM during scope caps - would prove immensely helpful...