Problem Interfacing with MaxSonar EZ1

[shrimpy]

Hey,
I'm trying to interface a ZBasic to a MaxSonarEZ1 (http://www.maxbotix.com/uploads/LV-MaxS ... asheet.pdf), and have been running into a rather annoying problem. Whenever I attempt to request a pulse stream and the first data bits reach the ZBasic, it resets itself, or sometimes just freezes. Something bad is clearly happening as the chip receives the pulses, I've tried transistor isolation so it's something more than over current. My code is below,
Thanks for your help,
Nathaniel

Code: Select all

'-----------------------------------------------------------------------------------------------------------------
Public SonarOQ(1 to 2) as byte                'Sonar Queues
Public SonarIQ(1 to 25) as byte
Public datain(1 to 10) as byte                   'Dump data bytes from queues here
Public erflag as boolean

Private const TX as Byte = 5                     'Connected to serial output of Sonar
Private const RX as Byte = 6                     'connected to input of sonar for requesting data

Sub Main()

  Call OpenQueue(SonarOQ, 2)
  Call OpenQueue(SonarIQ, 25)

  Do
    Call ClearQueue(SonarOQ)                     'Clears the output queue
    Call ClearQueue(SonarIQ)                     'Clears the input queue

    Call DefineCom3(TX, 0, bx0000_1000)          


    Call OpenCom(3, 9600, SonarIQ, SonarOQ)

    Call PutPin(RX, 1)                           'Trigger read cycle
    Call Delay(0.01)
    Call PutPin(RX,0)

    Call GetQueue(SonarIQ, DataIn, 5, 0.1, erflag)

    'Program never reaches this point with power to the sonar

    Debug.Print cstr(erflag)                     'Serial transmit a success?
    Call Delay(0.01)
    Call CloseCom(3, SonarIQ, SonarOQ)
  Loop
End Sub

[dkinzer]

Try the variation below. I increased the size of the output queue since queues require a minimum array size of 10 bytes. I also moved the DefineCom() and OpenCom() calls outside the loop - those only need to be done once.

There are some timing constraints described in the datasheet for the sonar device. For example, it requires 250mS after power up before it can take a reading.

You might want to modify the code, temporarily, to simply output the bytes that it receives. That way, you might get a better idea of what's happening.

Code: Select all

Public SonarOQ(1 to 11) as byte                  'Sonar Queues
Public SonarIQ(1 to 25) as byte

Public datain(1 to 10) as byte                   'Dump data bytes from queues here
Public erflag as boolean

Private const TX as Byte = 5                     'Connected to serial output of Sonar
Private const RX as Byte = 6                     'connected to input of sonar for requesting data

Sub Main()
  ' initialize RX pin, allow time for LV Max Sonar initialization
  Call PutPin(RX, 0)
  Call Delay(0.25)

  ' initialize queues and serial channel
  Call OpenQueue(SonarOQ, SizeOf(SonarOQ))
  Call OpenQueue(SonarIQ, SizeOf(SonarIQ))
  Call DefineCom3(TX, 0, bx0000_1000)          
  Call OpenCom(3, 9600, SonarIQ, SonarOQ)

  Do
    Call ClearQueue(SonarOQ)                     'Clears the output queue
    Call ClearQueue(SonarIQ)                     'Clears the input queue

    Call PulseOut(RX, 0.01, 1)                   'Trigger read cycle

    Call GetQueue(SonarIQ, DataIn, 5, 0.1, erflag)

    Debug.Print cstr(erflag)                     'Serial transmit a success?
    Call Delay(0.05)
  Loop
  Call CloseCom(3, SonarIQ, SonarOQ)
End Sub

[shrimpy]

Thanks for your help, similar changes seem to have fixed it although I still worry it's a more intermittent problem..


On another note I need to poll through 4 sensors using the same com channel (different input pins), so I assume I need to close the com line using the closecom command, then redefine it and reopen it (without reopening the queue), but nothing I've tried seems to work and the moment I close the com line it seems to completely stop working. I never had this problem with the basicX and I'm completly lost as to what I'm doing wrong,
Thanks,
Nathaniel

[dkinzer]

similar changes seem to have fixed it although I still worry it's a more intermittent problem.

If you're worried about this I would suggest going back to the original code and making the changes incrementally in order to identify which changes affected the result. With that information, we can probably determine whether there is an underlying problem or if the result was expected.

I need to close the com line using the closecom command, then redefine it and reopen it (without reopening the queue), but nothing I've tried seems to work and the moment I close the com line it seems to completely stop working.

This is a known problem. See http://www.zbasic.net/forum/post-3551.html?#3551 for the workaround. We expect to release a VM update shortly that, among other things, addresses this issue.