Struggling with millis() for two tasks

Here's the wokwi


It is exactly you code except I
  • changed the LED pins for wiring convenience
  • made D6 INPUT_PULLUP, understand you can use INPUT from external source
  • commented in the 4 second video segment length
  • made the brief flash of the blue (!) LED 100 ms

So no significant code changes.

I have developed a high degree of confidence in the wokwi simulator. It does let you power servos from the Arduino and use LEDs w/o series resistors, so the analog side is not full fidelity.

But the program flow, logic and timing are rock solid. The sim uses the same tool chain to create code as theIDE, then executes that code on a simulated AVR at the machine code level.

Sorry I missed your comment on the healthy long trigger pulse. TBH I am in the habit of mostly ignoring comments (!).

Comments can be redundant, misleading, wrong or any combination of those, code is what actually makes the thing do whatever it does.

No comment on your comments! I did benefit from them, just missed the answer to my question.

You can save a copy of the wokwi and go from there if the simulator is helpful.

a7

Many thanks for the detailed follow-up.

I've no idea why, but the simulation seems to part from reality in one major way. On triggering with a brief press on the button (emulating the low from my motion sensor) it correctly delivers two presses (to start the video). But to end the video it again presses twice instead of a SINGLE press.


I'm determined to persevere with learning how to use wokwi. This is despite being unable to do so properly in my iPad's Safari browser because of having no paste facility. So I'd much appreciate it if you can spare a little more time to get going. And if we can be excused for going a tad OT.

I'm struggling to draw a test schematic from scratch. Perhaps because strangely the list of parts does not include the UNO itself? So I started with your neat schematic. I deleted all but the UNO, and added an LED (ensuring it was blue!). Similarly, I deleted your code and pasted in my trivial example.

But how do I proceed from here please? If I try 'Save a copy', nothing appears to happen. There's no 'Save As...' dialog. And a search of my PC finds nothing relevant. What type of file does it create and what sort of name?

If instead I use 'Share Project' it appears that it would save this link:

That's the the one you gave me, so it would presumably overwrite yours?

Perhaps a 'shared project' is the only sort of 'Save' possible? If so, how did you give yours a unique name?

Terry
Tuesday 14 September 2021, 1751

I'll check a few things when I am at the big rig.

I don't know what happens if you haven't "signed up" and "signed in", so do make an account for yourself. I prefer anonymity / no signing up ever but caved in this case as I have for a handful of important things.

Just now the (my) wokwi was odd, but I'm on an iPad at the moment and I've already found it to be at least inconvenient, but it should make anything weird happen.

So if you are on a tablet, try it on a real computer.

Lastly, you may be running into one of the problems I am worrying you about - the KA pulse coming at a bad time with respect to the end of the video period.

More later. The wokwi has quite a bit of documentation as far as steering around the basic functions you expect, like save, rename &c., I think they concentrating on the actual thing, but most of the time when I've asked for help they point me into the docs, and I find that I had been less than thorough in my searching.

a7

OK, solved that naming problem a minute or so later! I'd tried Rename before but must have screwed it up, because on trying again it gave me a new link:
https://wokwi.com/arduino/projects/309726123310187074

So my surmise seems correct, i.e. any sims developed here are shared universally, so that's how an author recovers any work, yes?

I think they all share a large numbered name space, yes. But you can't overwrite my thing, I don't think.

But there is a "lock project" menu item, I usually lock things before I post them here, just to keep me from changing them myself and cutting the grass under other viewer's feet.

a7

You were quick off the mark, so we crossed in the ether!

The KA is the only culprit I can think of, but if so that's a worrying flaw.

My test was on my Win 10 PC.

The wokwi works perfectly, that is to say it does the your code will do IRL. 99.999
percent on that.

Maybe the iPad screen refresh makes the servo twitches look funny. I don't want to start any kind of war, but they are "5 by 5" on my iMac. Could it be that Windows or the machine you run it on are introducing an "iPad" effect?

So - for testing make the sweep and gap between them quite longer. I used 500 milliseconds and the iPad version didn't look so odd anymore. Natch you'll want to switch back to the timing that works in the real version later.

  • Comment out just the Red Video timing section and see the KA work well.

  • Comment out just the Blue Yellow KA section and see the Video work well.

Human factors tip: light works faster on the brain here. Turn on the pilot LEDs in both sections before you make the servo arm move.

With the KA gap of 5 and the short Video test length, it's actually kinda hard not to get a KA tap after the end video tap.

Adding the scoot thing I suggested above fixes that: reset the KA tap timing right after the video finishes and you won't get a KA tap piling on.

The input pulse is plenty long, too long for 4 second testing in fact, but OK for the longer video interval.

Remains only the problem of getting a video initiation too very close to a KA tap. Imma let you have the fun of solving that, if it even is a problem for real. Estimated difficulty: you got this.

BTW/FWIW when I look at my own, locked, wokwi sims, the only menu option available is "Save A Copy", until I unlock it. I dare to hope that only I could do (unlock it), therefor others will only be able to save their own copy, not mess up mine.

Oddly, there is nothing to prevent one person from having multiple projects with the same name, which can be a bit confusing to say the leas. I am now in the habit of renaming anything I start with, empty sketch or copy, to something new, unique and, with any luck, meaningful.

It has been fun using the servo object in the simulator, and I think this is a nice project; there is a charm to using a servo to press a button. It reminds me of the old days when we weren't allowed to mess with Ma Bell's telephone equipment - let's just say there was some innovation involved in working around that when we bothered to do.

HTH

a7

As I said in my last post, my test was on my PC, not my iPad.

I haven’t read the rest yet…

Haha, sry, I meant maybe when I was looking at it on my iPad and it did seem to be not quite right that it was because the iPad.

Which is either or tru or false, I’m just not gonna bother with the iPad because, as I may have said, there’s enough more about it that makes it less than satisfactory. For wokwi.

a7

You were dead right about the cause being down to my code, not the excellent Wokwi. Sorry it took me so long to get that!

I thought the obvious correction would be to simply reset the KA interval timer directly after the video, as well as at the end of the KA section.

But that kills the KAs, so still pondering. Millis still gets me in a mess sometimes :slightly_smiling_face:

https://wokwi.com/arduino/projects/309884615328268865
T

This

previousMillis = currentMillis; // Reset, as KA not needed for 160s (5s test)

is in the wrong place. If you remove all your comments, you will see that you are resetting the previousMillis timer right before you test it.

Move that line of code into the video timing section; reset it directly after the servo tap that ends the video. So, only reset the previousMillis timer if you've actually taken a video.

But wait! There's more. currentMillis is hopelessly out of date by then, on account of the time spent filming… so use

previousMillis = millis();

But wait! There's still more: the KA section is using a possibly hopeless outdated "currentMillis" so that needs to be updated

currentMillis = millis(); 

before it is tested against previousMillis to trigger a KA photo.

I moved the illumination of the LEDs to assist my slow reflexes. Also I moved

prevTrigState = trigState;

into the if statement it is used for, where it belongs.

 if (trigState != prevtrigState) {

Why it worked where it was is no doubt some unintended luck due to the blocking nature of the video. I could run it to ground, but life too short. This is the kind of thing that will come out when you move to FSM/non-blocking techniques.

So with those changes

Sometimes little problems like this can only be found by playing computer, tracing through the code with your finger tip and making no assumptions about how you think things are working, just "run the code".

Even copious Serial.print(ing) can be misleading, as you are biased in your placement of those statements and implicit assumptions may go untested and unreported.

a7

Just for fun: on my way to eliminating all delay() calls anywhere, I added a little entertainment section:

The same thing would work better in the latest non-blocking version, and will work mostly perfectly in a totally unblocked program.

a7