Prop To Prop Signaling, Not Serial Communication

idbruce · 2011-05-25 10:23

Hello Everyone

Someone from Parallax once told me how to do this, but I forget the exact details. Anyhow here is what I want to do. I want to use a pin on Prop One to force a pin on Prop Two to go LOW. What are the exact details and hookup? My cable length is two feet, and I believe I was told it could be done with two wires and with or without a resistor. Any help that you may provide in providing a good outline will definitely be greatly appreciated.

Bruce

JonnyMac · 2011-05-25 10:33

This is pretty basic. On the slave Propeller pull-up the input pin (via 10K) to Vdd; this will keep the pin in a known state should the control device become disconnected. On the master side pull that pin low to create the command and release it (back to input state) when the command is finished, etc.

pub set_cmd(pin)

  outa[pin] := 0                                                ' set for low
  dira[pin] := 1                                                ' output mode


pub clear_cmd(pin)

  dira[pin] := 0                                                ' release to pull-up

Note: Input pins should never be without a pull-up or pull-down. The scheme described above assumes you will never drive either pin high as this could cause a short circuit if the other is driven low. On the slave side you can use this method to get the status of your input pin (0 = active, 1 = not active)

pub input(pin)

  dira[pin] := 0                                                ' ensure input mode

  return ina[pin]                                               ' return pin state

idbruce · 2011-05-25 10:41

@JonnyMac - Thanks Jon I definitely appreciate it. I am finally getting around to adding that Cash Register wave sound to Wire Bending CNC using my CDROM hack and your jm_Demo_Board_Cylon.spin file. Everything sounds, works, and looks good, just needed this final detail. Thanks again Jon.

Bruce

idbruce · 2011-05-25 22:50

Okay, I must be doing something wrong, but I don't see it.

The wave player was working without relying on a input for a trigger, so the problem definitely lies in the trigger or the code for the trigger.

Here is my code sent from the Master

  OUTA[SOUND_OUTPUT]~   ' set for low
  DIRA[SOUND_OUTPUT]~~  ' output mode
  DIRA[SOUND_OUTPUT]~

And here is the code for receiving by the Slave

PUB Main
  DIRA[4]~
  REPEAT
    IF NOT INA[4]
      WavCog := COGNEW(PlaySound(7, @CashRegister, 1), @Stack) + 1
      WAITCNT(CLKFREQ / 100 + CNT)

The idea is to wait for Pin 4 to go low and then play a wave file on Pin 7.

Below you will find a schematic of the hookup between the slave and the master.

Do you guys see anything obvious?

Bruce

kuroneko · 2011-05-25 23:07

idbruce wrote: »

Okay, I must be doing something wrong, but I don't see it.

So what is or isn't happening? I assume SOUND_OUTPUT is #10, can you catch the pulse on the slave side with a waitpne(|< 4, |< 4, 0)? It may well be too short to be noticed the way the code is written right now.

idbruce · 2011-05-25 23:16

How's it going Marko? Good to hear from you.

Yes, SOUND_OUTPUT is Pin 10 on the master.

So what is or isn't happening?

If I run the master code, the slave does not play the wave file

I have not tried WAITPNE. I was also thinking that it may be to fast a signal, but I was not sure. What about making the trigger from the master a little longer with something like this?

  OUTA[SOUND_OUTPUT]~   ' set for low
  DIRA[SOUND_OUTPUT]~~  ' output mode
  WAITCNT(CLKFREQ / 100 + CNT)
  DIRA[SOUND_OUTPUT]~

kuroneko · 2011-05-25 23:20

idbruce wrote: »

What about making the trigger from the master a little longer with something like this?

Sounds OK, I just checked the pulse length (dira on/off) and it's 512+ cycles already, that's ages ... We should make sure that the pulse actually arrives at the slave. Another thing is that the cognew may fail. But that's unlikely given that you mention it working without trigger. Stack is big enough?

Update: The slave repeat loop in it's current form can't keep up it seems. I sent pulses once every second and I don't get a nice blink effect. So either widen the pulse or use a form of waitpxx on the slave side (provided that's all the loop does).

idbruce · 2011-05-25 23:29

@kuroneko - As it was originally written, COGNEW succeeded and the stack space was large enough to work properly. Here is a copy of the original working code.

var
  long  WavCog 
  long  stack[64]
pub start
  WavCog := cognew(playsound(7, @CashRegister, 1), @stack) + 1

How can I ascertain whether the slave actually receives the pulse? LOL I was relying on the wave sound for that

kuroneko · 2011-05-25 23:32

Looks like the pulse arrives but as I mentioned above, the current slave loop can miss it.

repeat
  waitpne(|< in, |< in, 0)
  !outa[LED]

idbruce · 2011-05-25 23:35

@Marko - Alright, I will try widening the pulse and see what happens. Thanks for the help and the tips Marko. I miss working with you, and I hope all is well with you and your loved ones. You are a very decent guy.

kuroneko · 2011-05-25 23:40

Lucky I didn't shave for a while, otherwise you'd see me blush

Would be ridiculous if we don't get this working.

idbruce · 2011-05-26 00:06

@kuroneko - Okay I tried the following code, but that did not help.

  OUTA[SOUND_OUTPUT]~   ' set for low
  DIRA[SOUND_OUTPUT]~~  ' output mode
  WAITCNT(CLKFREQ / 100 + CNT)
  DIRA[SOUND_OUTPUT]~

And then I altered the slave code as follows and the wave file plays on startup, but does not play from the code above.

PUB Main
  WavCog := COGNEW(PlaySound(7, @CashRegister, 1), @Stack) + 1
  DIRA[4]~
  REPEAT
    IF NOT INA[4]
      WavCog := COGNEW(PlaySound(7, @CashRegister, 1), @Stack) + 1
      WAITCNT(CLKFREQ / 100 + CNT)

And now I am going to try the following

PUB Main
  WavCog := COGNEW(PlaySound(7, @CashRegister, 1), @Stack) + 1
  DIRA[4]~
  repeat
    waitpne(|< 4, |< 4, 0)
    WavCog := COGNEW(PlaySound(7, @CashRegister, 1), @Stack) + 1
{
  REPEAT
    IF NOT INA[4]
      WavCog := COGNEW(PlaySound(7, @CashRegister, 1), @Stack) + 1
      WAITCNT(CLKFREQ / 100 + CNT)  
}

kuroneko · 2011-05-26 00:17

In that case I wouldn't worry about playing a sound right now. Just see that you catch the pulse reliably and indicate that with an LED.

Just occured to me that if you widen the pulse you may start several cogs trying to play the wave file which will have interesting results (pin/stack usage). So keeping the pulse small and waiting for it may be better.

idbruce · 2011-05-26 00:17

@kuroneko - Okay there is a definite problem with the output from the master. With the input cable disconnected from the Master, the wave file plays on startup. But then if I try it with the cable connected, no sound plays. This is going to be a real pain, because the Master is a difficult board to get at.

Bruce

kuroneko · 2011-05-26 00:36

Can you re-program the master and output a low-freq wave on this pin, i.e. something easily verifiable on a multi-meter (unless you have an LED ready)?

idbruce · 2011-05-26 00:59

@kuroneko - I assume you ask that because the slave may be the problem, instead of the master.

Okay here is the scenario.

The bending cnc creates a spring. When it is complete, the bending cnc use a linear actuator to push the spring from the table. Before returning the linear actuator to a home position, the bending cnc uses the InterComm object

to send an indication to the Interface that a spring is leaving the table. The interface then sends a low signal to the wave player to play the appropriate sound. Not that that helps us any, but I thought you might like to know whats happening, so you can better understand my next plan of attack.

Okay so here's what I am going to do, because I do want this sound working!!! LOL I have a lot of time wrapped up in this nonsense and I want it working.

When the interface receives the signal from the bender cnc, I am going to have it output to the piezo siren instead of the wave player, just to verify that the interface is getting and sending signals at the appropriate time.
I am going to fabricate a LED test rig to replace the wave player. Dependant upon the outcome of the test, I will either switch input pins on the wave player, or I will check the integrity of circuitry of the interface board. Hopefully, the problem lies in the wave player, because that is much easier to work on.

Bruce

EDIT: Additionally, I have another hard to find problem within the cnc machine, and this current problem may help me find the other problem.

kuroneko · 2011-05-26 01:05

Invoking the wave player several times is not flying (pulse too wide) because you then start multiple SPIN interpreters on the same stack. To protect yourself from that have some busy indication which gates the wave start sequence. Anyway, first I'd like to see the pulse coming into the slave.

[COLOR="blue"]busy[/COLOR] := FALSE
  REPEAT
    IFNOT INA[4] OR [COLOR="blue"]busy[/COLOR]
      [COLOR="blue"]busy[/COLOR] := TRUE
      WavCog := COGNEW(PlaySound(7, @CashRegister, 1), @Stack) + 1
      WAITCNT(CLKFREQ / 100 + CNT)

  ' [COLOR="blue"]busy[/COLOR] is global and should be reset when the wave player finishes

idbruce · 2011-05-26 01:18

@kuroneko - I will let you know later today what I find out. As always, thanks for you assistance. At least I now have some direction. I also just did the swap to the piezo siren and it did not work, so it appears that I have two problems. But the piezo swap just appears to be a coding error. I will know more later today.

Bruce

idbruce · 2011-05-26 06:23

@kuroneko - Okay here is what I discovered.

The bender cnc communicates with the interface properly, and the interface is capable of sending a signal on Pin 10, as proven with the code below. Which further establishes that Pin 10 and the cable are okay. The test code below lit up a LED for 1 second at the appropriate time. The problem must lie in the circuitry of the wave player or Pin 4 within the wave player is bad.

    REPEAT
      REPEAT WHILE BenderInterComm.IsNewDataAvailable == FALSE
    
      BenderInterComm.GetDataFields(@DataField1, @DataField2)
      IF DataField1 == 20 AND DataField2 == 0
        DIRA[SOUND_OUTPUT]~~
        OUTA[SOUND_OUTPUT]~~
        waitcnt(clkfreq / 1 + CNT)
        OUTA[SOUND_OUTPUT]~

Bruce

kuroneko · 2011-05-26 06:28

Not sure how easy access to the slave prop is but now I'd try getting the pulse into e.g. pin 4 and light another LED controlled by the slave.

idbruce · 2011-05-26 06:40

@kuroneko - The slave prop(wave player) is very easy to get to because it is a seperate and detachable entity of the machine. A little aggravating, but much easier to work on than the machine itself. The Protoboard used for the wave player is a salvaged and dissected board. Perhaps thats why it is giving me problems.

I will now add a permanent LED to the wave player for future diagnostic situations. I will also alter that code so that it does not rely on the same stack. That was just for test purposes anyhow.

kuroneko · 2011-05-26 06:44

idbruce wrote: »

I will also alter that code so that it does not rely on the same stack.

Meaning? I'd have thought that playing one sample at a time is enough, i.e. you just have to make sure that it's only triggered once (or if triggered before it finished playing it should ignore the other events).

idbruce · 2011-05-26 08:00

@kuroneko - Okay first the test code

Test code for slave (wave player)

CON
  _CLKMODE      = XTAL1 + PLL16X                        
  _XINFREQ      = 5_000_000
PUB Main
  REPEAT
    IF NOT INA[4]
      DIRA[16]~~
      OUTA[16]~~ 'Shine brightly my beautiful LED
      WAITCNT(CLKFREQ / 1 + CNT)
      OUTA[16]~
      
      WAITCNT(CLKFREQ / 100 + CNT)

Test code for the master

    REPEAT
      REPEAT WHILE BenderInterComm.IsNewDataAvailable == FALSE
    
      BenderInterComm.GetDataFields(@DataField1, @DataField2)
      IF DataField1 == 20 AND DataField2 == 0
        OUTA[SOUND_OUTPUT]~   ' set for low
        DIRA[SOUND_OUTPUT]~~  ' output mode
        WAITCNT(CLKFREQ / 100 + CNT)
        DIRA[SOUND_OUTPUT]~

Alright now here is the results.

With the slave operating by itself, with no cable attached from the master, the LED does not light.
With the cable attached, and no power going to the master and no signal coming from the master, the LED turns on and off approximately every second, with a very short off time.
With the cable attached, and power now provided to the master or signal sent from the master to the slave, the LED turns on and off approximately every second, with a very short off time.

I hate to say it, but if that wiring diagram provided earlier looks correct, than I would say that something is wrong with Pin 4 on the Slave or with Pin 10 on the Master.

kuroneko · 2011-05-26 16:34

idbruce wrote: »

With the slave operating by itself, with no cable attached from the master, the LED does not light.

With the cable attached, and no power going to the master and no signal coming from the master, the LED turns on and off approximately every second, with a very short off time.

With the cable attached, and power now provided to the master or signal sent from the master to the slave, the LED turns on and off approximately every second, with a very short off time.

Given that you have a pull-up on that line this just sounds wrong. The behaviour described is clearly one of the pin seeing low. Any chance of stimulating the pin from within the slave prop (spare cog which plays master) bypassing any external connection (no pull-up, no connection to master)?

idbruce · 2011-05-26 21:48

@kuroneko - Well it looks as though I will have to rip out the interface board for an up close inspection, because the following code works flawlessly. This is going to be a real pain and I am not looking forward to this task.

That was a very good recommendation for test setup to isolate the problem from board to board. Thanks Marko.

However, as previously mentioned, I was having other issues with losing power to that board and this may have something to do with that. So perhaps this is a blessing in disguise.

CON
  _CLKMODE      = XTAL1 + PLL16X                        
  _XINFREQ      = 5_000_000
VAR
  LONG  Stack[64]
PUB Main
  COGNEW(SimilulateCable(5), @Stack)
  REPEAT
 
    IF NOT INA[4]
      DIRA[16]~~
      OUTA[16]~~ 'Shine brightly my beautiful LED
      WAITCNT(CLKFREQ / 1 + CNT)
      OUTA[16]~
 
      WAITCNT(CLKFREQ / 100 + CNT)
PUB SimilulateCable(StimulationPin)
  REPEAT
    OUTA[StimulationPin]~
    DIRA[StimulationPin]~~
    WAITCNT(CLKFREQ / 100 + CNT)
    DIRA[StimulationPin]~
    WAITCNT(CLKFREQ * 5 + CNT)

idbruce · 2011-05-26 21:53

@kuroneko - Of course I will check out the cable before ripping out the interface board

kuroneko · 2011-05-26 21:54

Out of curiosity, is the pullup part of the slave board? Otherwise I can't see your similulation working.

idbruce · 2011-05-26 21:57

@kuroneko - Yes, the pullup and test stimulation pin are both on the slave board. That is what you wanted me to do isn't it?

Bruce

kuroneko · 2011-05-26 21:59

Correct. So it looks like a flaky connection. I know I mentioned no pullup and I would have written the simulator in a different way (to avoid the need for a pullup). Just so that we are on the same page.

idbruce · 2011-05-26 22:08

@kuroneko - The pullup was already on that board and connected to pin four, so I assumed that was the pin you wanted me to stimulate since it is the trigger.

Bruce

kuroneko · 2011-05-26 22:15

Yes, the idea was to take cable and master out of the equation. So triggering a wave player shouldn't be the issue then.

Prop To Prop Signaling, Not Serial Communication

Comments