COUNT?

[BITMOVER]

I am having an issue with the 'COUNT' command.

From the manual..

main:
count 1, 5000, w1
debug w1
goto main

It is supposed to count the transitions on pin1 in 5 seconds and put the result into W1, showing them in the debug window. Correct?

What happens..Nothing!
The program loops from the goto back to "main", does not slow at the count statement, w1 does not increment and the debug window (since I am running this on the simulator) does not open. All applicable chips were tried and the editor is 5.2.1

Is it me?

Len

 

[eclectic]

Len.
Please run this, and see what happens.

main:
sertxd ("start",cr,lf)
count 1, 5000, w1

sertxd ("stop  ",#w1,cr,lf)
sertxd (cr,lf)
goto main

It goes very fast in the simulator, but
works perfectly on a real chip.

You can adjust the simulator speed,
View >>> Simulator >> speed bar


e

 

[BITMOVER]

eclectic,

Thanks for your speedy response!

I ran the code, and pretty much the same thing happens. The simulator shows it just running in a loop: The serial window shows activity but W1 is not shown and never changes from zero regardless of how many times I pulse the #1 pin

Next What?

PS: Simulator is set as slow as possible!

 

[Technical]

You can't click your finger anywhere quick enough to simulate a count command!

Therefore a different method is used. You enter the number you want in the 'generic' number box on the simulation panel. This number is then transferred to the variable.

To pause the program and change the values simply put a breakpoint (click over the line number) before the count command.

 

[BITMOVER]

Technical,
Thanks! That worked, but, I'm still miffed!

If the transitions are counted in a time window, let's say 10 seconds, why doesn't pulsing the input 3 times in 10 seconds place '3' into w1?

I would think that the program would halt at the 'count' command for the period of time set, count the incoming pulses, then continue, but it does not? It runs right through the statement line.
Is there a 'minimum pulse speed" ?
Aside from all that, the manual cautions " Take care with mechanical switches...."

Clear as mud!

Len

 

[Technical]

What is your project?

If you are trying to count, for instance, just 3 switch pushes in 10 seconds, count is probably not the correct command for you. Count is designed for very high frequency pulses, it has a very quick response time, for instance counting light pulses through an opto-slot on a wheel as it rotates.

This response time is quick enough to detect the metal contacts 'bouncing' against each other as a mechanical switch closes - you do not get a clean 'snap' closed, the metal bounces a few times. Therefore if you think you have just pressed the switch 3 times, you may in fact get a reading of, for instance, 8 by using the count command (3 closures + 5 bounces).

 

[BITMOVER]

Technical,
I completely understand 'switch bounce'.

The pulses to the picaxe input will be from an opto-coupler that is being driven by pulses from another Picaxe.
Picaxe 'A' will control Picaxe 'B' by sending a 24 VDC pulse through the previously installed wiring system. Serial data will not work since this is common building wire, not shielded, or 'cat' anything. Opto-couplers will isolate the Picaxes from the wiring.

I need to count the number of pulses in 5 seconds, with a typical count being 1-10. These pulses will likely be .25sec long with a 50% duty cycle to cause the distant end Picaxe to respond. 1-2 pulses, do nothing it maybe spikes : 3 pulses do 'A', 4 pulses do 'B' .....

Probably 'Settimer' would be an answer to the timing but I want to use a smaller chip (08/14)and they don't support that feature!

And so, the issue still is...counting the pulses! I want to see 'count' work in the simulator!
I am reasonably sure the 'simulator' inputs don't bounce, but, if they did, I would still get a count in W1, although in error!

Getting in deeper!

Thanks,

Len

 

[Michael 2727]

Have you tried this on an actual chip and not just in the SIM first ?
The simulator can only do so much, a dynamic input/s is not exactly one
of them. The Generic input button is limited but better than nothing.
The simulator is great for checking/debugging code but you can't beat a real chip

 

[BITMOVER]

Michael,

No, I have not yet done this in the hardware stage.
Yes, I am surprised that this command appears to not simulate, and I realize the simulator has limitations.
Since the count rate is so low, I would really expect to see some count!
Maybe Technical will have further info...

Thanks

Len

 

[Technical]

The 'count' simulation does work. It loads the value in the generic value into the variable.

It may not work the way you specifically want it to here, but the opposite would apply to someone who wants to input, say, 5322 to indicate rapid pulses from an optoisolator. Using your suggestion they would have to click 5322 times...

The current situation, as with all simulations, is a compromise and will work in both scenarios. The on-screen simulation can never exactly mirror the real life usage.

 

[SD2100]

Technical,
Serial data will not work since this is common building wire, not shielded, or 'cat' anything.

Have you tried sending serial data, it will work through just about anything !!!

 

[BITMOVER]

Simulator Shortcomings!

To Technical:

One of the significant reasons there are a lot of questions on this forum is confusion!

The Simulator is part of the Program Editor, and as such most people, like myself, incorrectly assume it will work with all the listed commands, and indeed it does with many. However, there are some instances where it falls flat on it's face.

So, rather than 'we the people' pulling our hair out, how about some definitive list of the commands that it does not support, its issues and shortcomings so we don't try in vain to make it work when it cannot!

There is no malice intended, just a request for information that would guide us along the path. Post it here, as an addendum to the manual, whatever, just get it into the public eye. After all, the Picaxe is an 'Educational Product', is it not?

Len

PS: It might even make your job easier!

 

[eclectic]

Len.
from Manual 1, page 51

"The ‘generic’ value operates in a similar manner (0-65535) and is used by
the following commands as the input value: count, pulsin, readadc10,
readtemp, readtemp12 etc."

I missed that one, this morning :-(

e

 

[BITMOVER]

Phil75,

No, serial is improbable, here's why.
There are three wires in the system, with parallel taps all over the place. One wire is common, one is 24 VAC and the other will be used for this project. This is installed in conduit in a large office complex so adding or replacing the wire is not an option.

My design is to use the unused wire and the common. First I'll send a 24VDC polarity reversal to wake up the remote chips, then send a pulse train of 24 VDC pulses with another polarity reversal at the end. Sort of a basic start- data-stop arrangement. The remote picaxes will then provide outputs based on the count.

Since this is a parallel system, all the picaxe's would receive the same code and responding in unison, which is desired.

I think the 24VDC, with the polarity reversals to frame the data, the isolation provided by the opto-coupler and ignoring counts less than a few will offer sufficient noise immunity so there'll be no glitches.

.....if only I can reliably count the pulses!

Now it's off to the breadboard!

Len

 

[BITMOVER]

electic,

I caught that in the manual, but it doesn't say it doesn't work? More like a feature!

It seems the simulator is due for an upgrade!
With the 40x Picaxe there really should be more buttons & lights so that the pins are properly simulated. If you use a 40x, with all the pins, some as inputs, others as outputs, the simulator falls dead. You can't tell what's happening!

By the way, unless I'm out in left field, it looks like 'button' won't simulate either!

Len

 

[BeanieBots]

As with any software, there will always a few "bugs" and the authors will often not know until they are pointed out. As for example the "button" command quite recently.
When a bug is pointed out, Rev-Ed are usually very quick to correct it.

We also need to get this into perspective.
First off, the "count" command DOES work in the simulator. It might not be how YOU want it to work but it is how MOST would want it to work.
Also, don't lose sight of the fact that both PE and the simulator are FREE.

The "Product", namely the chips and a method of programming them is absolutely fine and any genuine bugs in either system are very quickly put right. The 'simulator' is a nice to have aimed at education. If you want a better simulator, have you considered BUYING one?

 

[BITMOVER]

BeanieBots,
If I turned over a stone, I apologize.

I have no real problem with the software, the simulator or Rev Ed. I started with Parallax years ago and will not look back. I feel the program editor is super, and the simulator is better than running everything in realtime. But, free or otherwise, if a product has has limitations, by design or default, just let them be known! It's tough to spend hours thrashing around to solve a small problem to later find your were never going to solve it. Even worse when it appears to be known by some and only through multiple posts on a forum like this, are you able to see the true issue.

So, you think a 'paid for' simulator will be better? Well maybe it would be. I have VSM. It's cranky and hard to really be productive with.

What simulator would you suggest?

Len

 

[BeanieBots]

No appology required and I honestly don't think there is any stone to be turned over. I just felt you were making it a bigger issue than it is or expecting more from it than is realistic to expect.
I really do think any "short commings" are out in the open. Admittedly some things might be a little obscure, but certainly not by intention.

For simulation, it really does need to be VSM for anything PICAXE related.
As you say "It's cranky and hard to really be productive with. ". That's because you need to set up EVERYTHING that can possibly interact with each other. Not so with the PE simulator, and hence the "limitations".
VSM can be quite quick once you get used to it.

Personally, I hate any form of simulation. If it's complex enough to warrant simulation, the simulation is unlikely to simulate accurately enough. More to the point, the user inputs and model design are not likely to be accurate enough. In most other cases, the real thing is just as quick and easy and won't give you any surprises that a faulty simulation model might otherwise do. But that's just my opinion. I regard the "simulator" more as an extension to the syntax checker. Great for double checking what the result of some obscure maths might be or to see what happens if you force an input to a particular value. Most other things require interaction with hardware which it can't do.
With VSM you can add that hardware interaction. That is what you would need to do if you really want a system where you have to 'click' X number of times. Even then, I don't think of VSM as a simulator. I consider it a very good visualisation of a working PICAXE model ideal for education.

SPICE is THE simulator, but not much use for PICAXE. First, you would need to create a model of your PICAXE for it to simulate. The irony is that if you knew it's behaviour well enough to create the model, you wouldn't need to simulate it. It's a bit like making a peg to see if it will fit in a hole. If you have enough information to make the peg, you would certainly know it's dimensions and therefore know if it would fit the hole without needing to make it.

 

[BITMOVER]

BeanieBots,
I agree and understand.

I guess the real issue is that since the simulator works so well for many things, it's reasonable in to expect it to work for everything. For many it is a 'success feedback' tool. At least you know if the code is in the right direction and functioning. I said earlier that I started with Parallax and their software had no simulator. Write code, load it, test it, debug, and do it all over again. It sure got old.

So when something doesn't work, you glare at, look up and double check your code, which may be right. It's a hard time believing the simulator is really not simulating correctly. Like a meter that's in error, but only sometimes. It leads you astray until you know when the sometimes are!

Sure, the realtime hardware is always the best way, and the best simulators cannot emulate that environment, but in the early project stages, the simulator is really quite handy, and adequate.

So what's the objection to a list of the simulator's shortcomings so those issues can be avoided?

Len

 

[BeanieBots]

I think the problem with a list of short commings really depends on how they would be defined. That is, what is percieved as a short-comming to one person may well be a feature to another. Also, what can be realistically expected from a simulator which does not include hardware modelling? When was the last time you saw in a manual car brochure, "this car will stall if you just drop the clutch without applying any gas"?
I agree that HOW IT WORKS needs to be clearly explained and perhaps that aspect does warrant an overhall. Creating a manual in a manner which can be understood by everyone and is not excessively verbose is a very challenging task.
When it comes to genuine "bugs", if they are known at time of release, they are stated in the firmware.txt file.

 

[papaof2]

On the money!

Creating a manual in a manner which can be understood by everyone and is not excessively verbose is a very challenging task.

Until you've written a manual for other people to use, you will have no idea how hard it is to balance "understandable" against "verbose". Some years ago I wrote an introduction to a logic analyzer plug-in for a Tektronix 7000 series oscilloscope for techs who would be using it to maintain time division multiplex equipment. These were people with a lot of knowledge/experience; even so, a logic analyzer was new to them and the "how to" had to be phrased in terms of their experience. I don't remember how many drafts it went through...

John