Puzzled that child values are changed by parent

lardom

I modified a 'joystick' object from "rctime" which gave me 7 X-axis values and 7 Y-axis values to mcp3208 which gave me 17 x-axis and 17 y-axis values. The 'joystick' object works fine. When I call that object from the top object some of those values change. Before I rewrite the object to have fewer values I'd like some advice on what I should look for.
I did not have that problem with the lower resolution 'rctime'.

kwinn

Posting the code and wiring diagram would help.

JasonDorie

Yes, post the code as an attachment and it's much easier for people here to suggest what might be wrong. I'd start by looking to see if you're simply overwriting memory somewhere. If the original object only stored 7 values, and your new one stores 17, did you adjust the arrays that hold the values? Just a guess.

lardom

I attached the relevant code. "Joystick demo" is the top object. I'm still getting the error. From the top object I get "1" from 'x' and 'y' when the joystick is centered and "15" when I expect "16".
From "Buggy joystick" I get the correct values.

lardom

I attached the relevant code. The error is still present. From the top object (Joystick demo) I get "1" for 'x' and 'y' when the joystick is centered and "15" at the high extreme. From "Buggy joystick" I get the correct values.

Publison

It would be better if you did an archive from the Propeller tool:File>Archive the top object instead of splitting them out. Things may be missing.

lardom

Publison wrote: »

It would be better if you did an archive from the Propeller tool:File>Archive the top object instead of splitting them out. Things may be missing.

Done

Publison

Super!

JasonDorie

You're doing something that's a little bizarre that might be part of the issue:

    F_B := adc.in(0)   
    Case  F_B 
      0..20       : F_B := 16   'back
      21..380     : F_B := 15 

You're assigning F_B to a value, then using a case statement to re-assign it to a different value. Because this is running in a cog, the caller may be accessing the variable F_B between when you first set it and when you change it.

I'd alter the code to this:

PUB Inputs  | temp
  
  repeat
    
    temp := adc.in(0)   
    Case  temp 
      0..20       : F_B := 16   'back
      . . . 

I can't say for sure that's your issue, but it's a possibility. It might also be that the ADC method you're calling needs more stack space than you're providing, though 50 longs seems like it should be plenty. As a test, bump that up to 100 longs and see if you still have the problem.

lardom

JasonDorie wrote: »

You're assigning F_B to a value, then using a case statement to re-assign it to a different value. Because this is running in a cog, the caller may be accessing the variable F_B between when you first set it and when you change it.

I added a variable "temp" because it was clearly the correct thing to do but I got the same result. Then I tried raising the stack from 50 to 400 longs which had no effect so I took another look at the top object.
I commented the CASE loop and "Button press" then called the "Joystick" object directly. That worked.
It appears I should call for the joystick values before I call "Mode_select. If that doesn't work I'll start another cog.
Much thanks to you and Kwinn because I was completely out of ideas.

JasonDorie

Your code is also calling your js.GetFB function twice (the original code was, at least):

PUB Motor_Mode | Fwd_Bkwd, Rt_Lft

    Fwd_Bkwd := js.GetFB   'call GetFB once
    Rt_Lft  := js.GetRL
    
    pst.Str(String(pst#NL, "Fwd_Bkwd = "))
    pst.Dec(js.GetFB )    'call GetFB again

The pst.Dec() call should just display Fwd_Bkwd instead of calling the function again. Minor, and not going to be your bug, but it's a little odd and will be slower.

I don't understand what you mean by "before I call Mode_select" - it's a variable, not a function - I don't see a call to it anywhere, unless the code is different than what I'm looking at. Do you mean before you execute the case statement? I see no reason you should have to call the JS.GetFB function first.

lardom

JasonDorie wrote: »

The pst.Dec() call should just display Fwd_Bkwd instead of calling the function again. Minor, and not going to be your bug, but it's a little odd and will be slower.

I don't understand what you mean by "before I call Mode_select" - it's a variable, not a function - I don't see a call to it anywhere, unless the code is different than what I'm looking at. Do you mean before you execute the case statement? I see no reason you should have to call the JS.GetFB function first.

I made the change to pst.dec(). I appreciate the time you took to proofread my code. I've learned a lot from you. This forum has been my classroom.
I do think the case statement (which is what I meant) is the culprit but I'm not sure. I'll pinpoint it tomorrow.

JonnyMac

Most of my code swirls around the entertainment industry, and I've worked with clients that build camera pan/tilt heads. When using the MCP3208 remember that it can be a bit noisy, so averaging is important, and you don't have to do it very fast (i.e., using PASM to read the ADC is not necessary). In the attached demo I use a Spin driver for the MCP3208 which is called from a Spin cog that does a running, 4-element average on each channel at 30Hz. I pulled your scaling code into simple methods.

The code compiles, but I haven't actually run it.

There are many roads that lead to Rome. As we say here in Hollywood, this code is "for your consideration."

lardom

JonnyMac wrote: »

Most of my code swirls around the entertainment industry, and I've worked with clients that build camera pan/tilt heads. When using the MCP3208 remember that it can be a bit noisy, so averaging is important, and you don't have to do it very fast (i.e., using PASM to read the ADC is not necessary). In the attached demo I use a Spin driver for the MCP3208 which is called from a Spin cog that does a running, 4-element average on each channel at 30Hz. I pulled your scaling code into simple methods.

The code compiles, but I haven't actually run it.

There are many roads that lead to Rome. As we say here in Hollywood, this code is "for your consideration."

Thanks JonnyMac. Your 'robot joystick' code is golden. I see a ton of stuff I can learn. I'm going to try it out.
I actually spent the morning modifying my code and testing different approaches. I decided to accept the values that the CASE statement in the parent object is changing because "Mode_select" is a necessary part of my project.