Go Down

Topic: Don't mix two problems and think they are one (Read 2812 times) previous topic - next topic

Johan_Ha

If your subject follows this pattern: "I have a problem getting my stepper motor react to my light sensor", you will give an impression that you either don't know anything about coding or you haven't even tried to make at least one thing work or you simply hope for some ready code.

This kind of subject contains two problems, which deserve their own questions and own threads. First you have to learn stepper motors. Then you have to learn sensors. If you know well both and still don't make it, the problem is in your coding skills, which you have to improve before dealing with hardware like this.

People who can help you, see these two problems in your question, while you give the impression that you see only one. That makes it hard to keep up an interesting thread.
____________________

If you ask for help and write 'u' instead of 'you' because you think it's convenient, I will write 'no' instead of 'yes'. For same reasons.

lastchancename

Well said.
A lot of people say this in different ways, but it never hurts to hear it again!
Experienced responders have a nose for laziness, (they were beginners once)... expecting the poster to contribute to the learning experience.

wilfredmedlin

Always remember it's the simple Input => Process => Output model.

Read stuff in, ponder, output other stuff.

Keep Calm and call 0118 999 88199 9119725...... 3

Jiggy-Ninja

It's actually three problems:

  • Read the state of the light sensor.
  • Calculate what stepper motor output you want.
  • Command the stepper motor to perform the action you want.
Hackaday: https://hackaday.io/MarkRD
Advanced C++ Techniques: https://forum.arduino.cc/index.php?topic=493075.0

Robin2

#4
Mar 02, 2018, 04:04 pm Last Edit: Mar 02, 2018, 04:05 pm by Robin2
Very many Threads that I look at assume (for example) that if there is a line of code that detects a button press it must be immediately followed by the lines of code that cause something to happen.

Separating
  • the code {A} that collects information (for example button presses or instructions over a serial link)
  • from the code {B} that interprets the information
  • and from the code {C} that implements actions

makes program development much easier.

For example,  by seeing the job as 3 separate parts each can be thought about without the confusion of the other parts. And each part can be tested on its own.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

adwsystems

Very many Threads that I look at assume (for example) that if there is a line of code that detects a button press it must be immediately followed by the lines of code that cause something to happen.

Separating
  • the code {A} that collects information (for example button presses or instructions over a serial link)
  • from the code {B} that interprets the information
  • and from the code {C} that implements actions

makes program development much easier.

For example,  by seeing the job as 3 separate parts each can be thought about without the confusion of the other parts. And each part can be tested on its own.

...R
And don't build A, B , and C all at once. It will become difficult to tell what works and what does not.

1. Build A and test to make sure it has properly collected the information.
2. Build B and verify it correctly interprets the information.
3. Finally build C. Since you know A and B work, any problem with C is related only to C or you have a fundamental problem in A or B.

The use of subroutines will help isolate and build each aspect of the project.

I suggest (and do the same) to make three versions of the program A, B and C. In the case where you find a problem with the fundamental upon reaching point C. You can more quickly fall back, modify and retest A or B (wherever the problem may lie).

RIN67630

Once you get into coding several thousands lines of code, you might use the tabs functionality of the Arduino IDE.

I use to use many of them:

a) declarations, includes, functions, options
b) setup
c) menu
d) data processing
e) display (if exists)
f) serial reporting/debug
g) action/output/end loop

h) read-me (only comments, will later be placed at the beginning)
i) parked (commented out code)
j) library functions to which i am not yet familar (comments)


The tabs have the advantage that you can switch quickly between the blocks of code (the cursor remains for each tab where it was last)

The parked section enables me to roll back easily if some new code was rubbish
The library functions enables me to write new functions the right way until i have them permanently on mind.


adwsystems

@RING67630; you mention that you use one tab for all of the variable declarations. I tried to do something similar but none of the functions on the other tabs could find the variable (I kept getting undefined variable errors). What has to be done to make your arrangement compile?

olafelch

If your subject follows this pattern: "I have a problem getting my stepper motor react to my light sensor", you will give an impression that you either don't know anything about coding or you haven't even tried to make at least one thing work or you simply hope for some ready code.

This kind of subject contains two problems, which deserve their own questions and own threads. First you have to learn stepper motors. Then you have to learn sensors. If you know well both and still don't make it, the problem is in your coding skills, which you have to improve before dealing with hardware like this.

People who can help you, see these two problems in your question, while you give the impression that you see only one. That makes it hard to keep up an interesting thread.
I do think it's unfortunate that in a forum focusing on the issues facing newcomers to Arduino to be told that a typical situation will be looked down upon by at least one expert here.  It's perfectly possible that someone with a problem has tested each stage of the process, but at the last stage something doesn't work.  If anyone here has never experienced this then I sincerely congratulate them on their perfect lives.

The people who post queries here have a problem.  As and when I can help, I will. I understand that they may not use the perfect terminology, and they may be a bit out of their depth, but I've always considered that to be the whole point of a support forum.

I just hope that newbies aren't discouraged by such posts.

lastchancename

#9
Jun 01, 2018, 04:28 pm Last Edit: Jun 01, 2018, 04:28 pm by lastchancename
Many good observations.
One thing a specialist forum like this promotes - as you say - is theposter's  abiility to 'ask the right question'...!

A part of this is to use the correct terminology, which may be difficult for first timers, but this doesn't mean that google is broken - in order to explore the context of your own circumstances.

Most of the experienced responders have a nose for beginners that are lazy, and they will get the lead-on... expecting the to contribute to the learning experience.
There are also pompous a**holes that just want to sound superior, as well as meaning twinkies that just had a 'bad day' or too many stupid questions!
Experienced responders have a nose for laziness, (they were beginners once)... expecting the poster to contribute to the learning experience.

Juraj

@RING67630; you mention that you use one tab for all of the variable declarations. I tried to do something similar but none of the functions on the other tabs could find the variable (I kept getting undefined variable errors). What has to be done to make your arrangement compile?
put global variables into the .ino with the same name as the project folder
You can't write an Arduino sketch if you didn't learn programming. Not the language, but the concepts of programming - algorithms and data types.

Go Up