@iseries said:
I put the Quadrature encoder on a scope and found that they must be digital devices as I did not see any contact type noise. I saw nice even square waves on each pin.
What I did see was that sometimes there would be an A pulse but no B pulse or if going in the other direction a B pulse with no A pulse.
At first I thought that this was a 5 volt device and that powering it with 3.3 volts was a issue. It did not make any difference.
Industrial encoders of this type use open-collector drive, possibly either PNP (drives high) or NPN (drives low). They can be powered up to 24 volts and wired directly into plain PLC inputs (which always have the pull-up/down). They are intended for slow simple cut-to-length uses. Often combined with a VSD and induction motor, or maybe a cheap chopper and brushed DC motor.
I am not maintaining the links on this first post of this thread as well as I used to; I simply don't have the time with all of my other responsibilities at Parallax. Might be time to hire some help.
If this isn't working for people let me know and I'll modify my behavior
These are called enumerated constants. Generally, they are constructed like this:
value SYMBOL1, SYMBOL2, ...
SYMBOL1 will be set to value. SYMBOL2 will take the value of SYMBOL1 + 1
Getting to the example. In Spin, true has a value of -1. This means that ON will be -1 (all bits on), and OFF will be 0 (all bits off) because -1 + 1 = 0.
In Spin, false is 0, which makes NO 0, and YES 1.
See page 87 of the Propeller 1 manual for a detailed explanation.
08:22 PST -- Files have been updated since this afternoon's session. Thanks for joining in; I know this topic was a bit tough. I have tested with FlexProp on Windows and everything seems to work. The program 3 archive contains the configuration file for the base station XBee (which is run from XCTU) and has the prebuilt list of command messages that you can load from the terminal. The bug caused by overaggressive beautification has been fixed, and global message filtering implemented so that multiple nodes will not reply to global messages.
I'm updating the Stingray code to use API mode on the XBee's rather than the transparent mode I was using via P1. That should help slim down a lot of the code that sends and listens for commands.
Comments
Industrial encoders of this type use open-collector drive, possibly either PNP (drives high) or NPN (drives low). They can be powered up to 24 volts and wired directly into plain PLC inputs (which always have the pull-up/down). They are intended for slow simple cut-to-length uses. Often combined with a VSD and induction motor, or maybe a cheap chopper and brushed DC motor.
At the beginning of each P2 Live Forum, I try to remind people that the registration links are here:
https://www.parallax.com/category/events/
And you can also receive them by e-mail on Mondays by subscribing to the P2 Community newsletter from this link 3/4th the way down the page:
https://www.parallax.com/propeller-2/social-media/
And I announce them on Twitter here:
https://twitter.com/ParallaxInc
I am not maintaining the links on this first post of this thread as well as I used to; I simply don't have the time with all of my other responsibilities at Parallax. Might be time to hire some help.
If this isn't working for people let me know and I'll modify my behavior
Thanks!
Ken Gracey
Just finished video #1.
Question. The concept behind the following code is clear as mud here.
con
true ON, OFF
false NO, YES
Wouldn't #true be ON or YES?
And #false be OFF or NO?
RJ
These are called enumerated constants. Generally, they are constructed like this:
value SYMBOL1, SYMBOL2, ...SYMBOL1 will be set to value. SYMBOL2 will take the value of SYMBOL1 + 1
Getting to the example. In Spin, true has a value of -1. This means that ON will be -1 (all bits on), and OFF will be 0 (all bits off) because -1 + 1 = 0.
In Spin, false is 0, which makes NO 0, and YES 1.
See page 87 of the Propeller 1 manual for a detailed explanation.
That does seem a bit obfuscated. It would probably be a bit clearer if the symbols were assigned explicitly, such as:
ON = true
OFF = false
NO = 0
YES = 1
The Session 7 files are attached as standard archives
You will need XCTU to configure your XBee modules:
08:22 PST -- Files have been updated since this afternoon's session. Thanks for joining in; I know this topic was a bit tough. I have tested with FlexProp on Windows and everything seems to work. The program 3 archive contains the configuration file for the base station XBee (which is run from XCTU) and has the prebuilt list of command messages that you can load from the terminal. The bug caused by overaggressive beautification has been fixed, and global message filtering implemented so that multiple nodes will not reply to global messages.
No "hot swapping" of those XBee modules in a live USB socket, right @JonnyMac ?
Ken Gracey
It's not a good idea!
Was not able to attend the zoom event live, but viewed on YouTube today...
I quickly got 2 older XBee's and 2 Series 3 XBee's talking, via flexprop on a Mac
Will come in handy once my Stingray code is running on P2.
Thanks Jon!
We missed you, Dennis. Did you notice the shout-out? I'm glad all is working on your end. Have fun.
Got the shout out!
I'm updating the Stingray code to use API mode on the XBee's rather than the transparent mode I was using via P1. That should help slim down a lot of the code that sends and listens for commands.
Thanks again
Hopefully, the third demo will help you get started with the XBee side of dealing with API1 packets in your robot.
Here are the archives for Session 8