Widget Weight Counter using HX711 and LED Display – Feasibility Study

@will Nice!

@davee Hi Dave, Good news. Progress has been made (mostly thanks to you) as follows:

The division factor (phase four) has been found, and that has allowed for the serial monitor widget count to now appear on my screen, (phase five), and so far, it's been correct every time, even above 10 widgets!

Heading into phase six(!), I'm a little cloudy on how to proceed. I have made changes to the pin designations in the sevenSegLEDtest2 sketch to match my Arduino pin layout, (which now has pin 2 for the load cell amplifier data, and pin 3 for clock, along with 7 more pins, 5-11, for each of the LED segments). Also, obviously, the GND and 5V pins that power the amplifier are also connected appropriately to the UNO. I still have pins to spare if needed. The above pinouts result in the LED counting up from 1 to 0, over and over, every time the reset button is pushed.

What I'm confused about are the instructions for phase six. (Please note that the confusion stems not from your wording of what to do, but rather my inability to understand it as a first timer).  I know that the two sketches needed (sevenseg and WWcounter) both work fine by themselves, and you can only use one sketch at a time, but my (limited) reading about tabs has me thinking that the tabs only serve to clarify and separate the data in ONE sketch, and doesn't mean that I can use tabs to meld two sketches into one, now that I need them both to work at the same time. So, after trying to do some research on this, and not finding info that breaks it down small enough for my brain, I'm still in need of some guidance about how to set up the folders, and the tabs, and whatever else you think might help.

Thanks again. Bill

Hi Bill @billinfl, 

It is good to hear you have made some more progress.

----I think the basic question you are asking, is how to combine two sketches into one, which probably seems simple to someone with a C or C++ programming background, but maybe bewildering for those people whose first and maybe only, experience of C/C++ and embedded programmes, consists of the Arduino sketches that are either included with the IDE or published elsewhere, most of which are a single source file, revolving around the pair of functions void setup() and void loop().

I am considering, trying to concoct a little 'tutorial' on how to merge two sketches into one, if that would be helpful. I confess, I have never looked to see what is already available on the subject, so I might do a little digging and thinking, first, which might take a little longer than a simple answer to prepare, so please be patient.

-----------

As a 'teaser', I'll say that the use of two or more tabs, is one of convenience, not a fundamental requirement or methodology. It does not in itself, allow two sketches to merge into a single programme. Each tab, is really just a convenient way of including another code file into the 'new' overall programme. The content of each file must be 100% compatible with its companions.

--

We started with the concept of a Widget Counter, but soon realised, this involved a 'weighing machine' and an LED display, both of which were unfamiliar, and presented problems. So we decided to develop them, including testing, as separate entities, each with their own Arduino sketch, so that we didn't need to worry about driving the LED, when working on the 'weighing machine' and vice versa.

So, at this point, we have two separate and tested programmes, that we need to combine into a single programme, but because we know the whole machine will be relatively complex, we want to minimise the chance that the 'code surgery' will introduce new bugs. Remember, the reason for initiallly developing them as separate programmes, was to simplify a 'complex' task into two simpler tasks. We want to look for ways that minimise the chance that the combined machine has bugs, because being a 'complex' machine, itis more likely to have bugs that are tricky to find and fix.

It is quite possible and feasible to use selective cut and paste, plus some editing, to transplant the essence of the LED display sketch, into the weighing machine sketch, to make a single sketch which does all you need. However, the more editing operations (copy/cut/paste/edit text, etc.) that you do on the sketches, the greater the chance that you will accidentally introduce new bugs.

Whilst some changes will be needed, as far as possible, it would be a good idea if you could simply include two or more 'tested' constituent sketches into a single project.

Furthermore, it might be good, if the two files actually retained access to their original test code, so that if they later need to be updated, then the updates could be applied, and each tested independently, before re-merging them to produce a single updated project.

---------------

The above description is a kind of 'Happy ever fairy tale' of what we might aim for. We might not achieve everything we desire, but perhaps it gives an insight of what to aim for. Of course, such fairy tales usually involve more effort, and overcoming problems; this wil be no exception!

--------------

I don't expect this taster to help you achieve the marriage of two sketches into one, but does it provide a general background?

Any comments welcomed. Would a tutorial that tries to explain some of the concepts be of interest?

Best wishes, Dave

@davee Hi Dave. Warning; The following is probably too much information, but I am reminded of you asking me to always provide as much info as possible, so as to know what I'm trying to do, and where I stand, so here goes.Sorry if this info isn't technical, it's more personal, but I think it will help you know where I'm at.

As usual, your post was both concise and insightful. You asked if it provided a general background, and my answer to that is Yes, and then some. You have perfectly described the situation that I am faced with, along with some possible ways that you might (further) help me achieve that "Happy ever (after) fairy tale" ending. First of all, I need to say that I'm already sure that the ending is going to be a good one. By the time it's complete, this project will have taught me many interesting things about a new subject, and also connected me (electronically, anyway) with people who are willing to help by taking the time to share what they know, both of which are probably more important than the gizmo itself working properly. (if, of course, it ever does). So, it's a win-win for me already, regardless, which now brings me to the time issue.

Your kind offer of creating a "tutorial" to help me to better understand is really appreciated, but I wouldn't want you to take a bunch of time to prepare it, (which I now know would be really well thought out and comprehensive, coming from you), only to have it not be simplified enough for me to "take over from here" as they say. Let me clarify by giving you an example from just yesterday.

In an effort to try to obtain the information related to "combining of sketches", I spent a couple hours looking around online for info that I could understand enough to actually begin to mess around with my 2 sketches just to give it a go. (My goal was, and still is, to have accomplished the goal of having the project be a success, while still having done at least a little of the programming, rather than just having someone send it to me and say "Here you go,Bill, just hit enter"). After looking around, (and around), I chose one that had potential, for my level, anyway, so I tried to delve into it. Below is the opening description from the 8 minute video:

"Often, when you’re looking at Arduino project examples online, you’ll find something that does one thing you need, but it doesn’t do everything, and then you’ll find another example that does something else, but you need to combine these together. But how do we do that, and then still make the sketch work? Well, here's a very basic way. There’s four steps to do: Copy everything from above set up, then copy everything in set up, then copy everything in the loop, and then copy everything after the loop. After you do that, you need to look for duplicate variable names and duplicate pin names and then just change everything accordingly, and then your sketch should work".

Sounds pretty doable, even for me, right? Well, not so fast, because multiple viewings still left me pretty clueless.Now, I realize that even though his sketches were pretty basic, they weren't MY sketches, so the changes that were being made were foreign to me, and therefore pretty confusing, pretty fast. I can post the link to his video if you'd like, but the point I'm making is that I'm just not sure that I'm going to comprehend the information in your tutorial, and would feel pressured that your time could possibly be wasted on me. Look, I'll be blunt.....I was the kid in school who would listen to a teacher break something down up there at the chalkboard, so that everybody could pass the test on Friday. The teacher would ask, "anybody NOT got it"?, and I was just too embarrassed to be the only one to raise their hand. Call it a learning disability or whatever, 60 years ago I don't think they had a name for it, but I still have it, and it stinks sometimes. If I'm handed a piece of furniture and some directions to assemble, the first time the directions don't make sense, and I get confused, I ditch the directions, and the piece comes out perfect. It doesn't work that way for computers,(as far as I can tell, anyway). The good news is that I have always excelled at sports and physical occupations, so, to each his own I guess. So, if your up for it, knowing just how (ridiculously) slow you'd have to take it for me, I'm all ears.

Wow, that was embarrassingly long! Let me know your thoughts about the above, and once again, thanks for being out there. Bill

Posted by: @billinfl

↑

people who are willing to help by taking the time to share what they know, both of which are probably more important than the gizmo itself working properly. (if, of course, it ever does).

Don't feel bad about having difficulty merging two sketches into a single unit. All people write programs differently so it can be an awful experience even for experienced coders. Partly because they have their own way of doing things too and they're usually facing two different styles, one in each sketch 🙂

The person who gave you the 4 steps is technically correct but it's not very useful to a neophyte programmer. It's the equivalent of telling an artist new to sculpting to "take a block of marble and chips away anything that doesn't look like an angel".

To be more specific, you may find it helpful to determine which of the two sketches has the more complicated code or has the most code. That'll be your starting point (call it the base sketch) and you'll transfer code from the other sketch into this after you decide what you need from it.

The first thing to do is find out which pins are used in each sketch and determine if there are any pins that BOTH sketches will try to use. You'll need to identify them and CHANGE them to unused pins everywhere in the other sketch. After that you'll need to see if there are any variable names that match between the two sketches. If there are and they represent real usage differences, then again you'll need to change them everywhere in the other sketch.

We're doing all of these changes in the OTHER sketch to make sure we don't corrupt the base sketch.

After you identify and correct any conflicts, then you need to 'debug' the other sketch (but not the base sketch, since it hasn't been changed). That will identify (and give you a chance to fix) any errors introduced by the pin and variable name changes so far.

Then, we can get into 'merging' the sketches (make a and label a copy of the base sketch every time you make an update to it so that you can 'take a step' back to a known-to-be-working copy later if you need to). First add any include files to the base sketch. Re-compile every time you make any change and immediately fix and resulting error(s) or revert to the previously saved sketch and try again.

Then you can start copying the variables and declarations. If you can identify them, only copy variables and objects that are needed to perform the action required (i.e. if you can, strip out the prints and calculations that are only used to prettify the result).

That's enough to get you started with a bit more of an understanding of how to process the merging.

I would think that the next step should be to copy any subroutines and function present in the other sketch before working on the setup(). This is because there may be initialization routines that you'll need to complete the setup. Essentially the same sort of process is used to copy the other sketch's required setup() code into the base sketch.

And remember, recompile and fix any errors after every change. If you can't fix it, then revert to the previous working copy and check the new changes again.

If you get through this, then you'll be well equipped to add the other sketch code to the loop() section. If you can't get this far, say how far you got and come back and ask again.

Hi @billinfl Bill & @will,

  Thanks, Bill for your reply, which far from being 'too much', I actually found very useful. Also thanks Will for your contribution, which, as usual, is pertinent and accurate.

In short, I haven't time to collect my thoughts yet, but both of your contributions are valuable.

I offer no guarantees that anything from me will automatically mean you can "take over from here", but I'll try to go in that direction. I am expecting some questions. or perhaps I should say "I shall require you to ask some questions"  ... you may have been shy at school, but this is the moment to overcome that shyness. The 'stupid' ones, are the ones that pretend they understand, but haven't got a clue. Become a 'clever' one by asking questions!! I still remember observing one very capable lady in the distant past, who after completely changing her direction and learning in life, would thoroughly examine everything she was told, and then question the source of that information for every detail she had difficulty understanding. Unsurprisingly, she was one of the most capable, successful and informed students.

----------------

I am sure the quickest solution, would be for you to post the 'donor' sketches, and I know Will is capable of posting back a completed answer in less time than it takes me to boil a kettle, but although you will have a working programme, you will probably learn approximately nothing from the process, except to know it can be done.

----------------------

So, with all due respect to all, I am suggesting we try to help you get at least a basic understanding of the process.

Unfortunately, the only way to learn is to go through the pain of trying to do it yourself, complete with making a few errors that need to be fixed. So I am thinking of describing the process in terms of a very simple, but totally useless 'machine', as a contrived example. I am hoping that I can include sufficient detail, for you to at least comprehend the process. I should however warn you, that learning to programme computers is a somewhat 'alien' concept to most people. I still recall my first encounters with a computer, half a century ago, and a bit like 'How do I turn a box full of unconnected bits of wood and screws, etc. into a functional cabinet?', it started with a totally puzzled look, but gradually become clearer as I began to 'play with the parts', and see the relationships of the different parts with each other. There was a part of that process, that I didn't hear or read at the time, but had to discover for myself.

--------------

BTW I hated all types of sport at school, probably because I was totally useless at it. I do read the instructions to try to assemble things. But I was also too shy to ask questions, and would never volunteer any answers, so I understand that issue, even if I still don't know how to kick or catch a ball.

--------------

So, if you are up for the challenge, I need to do a bit of thinking as well.

Please let me know of any more thoughts, experiences, etc. Trying to explain something to someone you know well, in the same room, can be difficult. When you have never met that person, and they are communicating to you by a contrived email system, is an order of magnitude more difficult.

Best wishes, Dave

@DaveE, @Will

I would be very interested in your proposed tutorial on how to merge programs. I am NOT a professional programmer. However, I do have some (limited) experience with C/C++ and I have been working in Python/Micropython recently on small projects. As my projects become more involved, I can see a time (rapidly approaching) where I will want/need to combine several simple programs into a larger more complex program to get the job done. I was able to follow (and understand) Will's (@Will) discussion above without too much trouble. I am interested to hear your thoughts on how to go about this, should you decide to proceed with your tutorial.

Thanks and regards,

Lee 

Posted by: @lee-g

↑

I am NOT a professional programmer. However, I do have some (limited) experience with C/C++ and I have been working in Python/Micropython recently on small projects. As my projects become more involved, I can see a time (rapidly approaching) where I will want/need to combine several simple programs into a larger more complex program to get the job done.

As long as you understand the basic pattern you can adapt the desired parts of one sketch into another. It happens all the time, after you finish your first project you decide that you want to use a certain display instead of just using the Serial Monitor. So then you have to dig out sample code for the new display and merge that back into your own sketch.

I know from previous posts that you aren't a total newbie programmer so it'll be a lot easier for you because you'll have a better understanding of which parts of the sample sketch's code is essential for the operation of the display and what portions are only used to illustrate the operation. And so it'll be easier for you to determine which parts need to be changed and which parts will need to be moved.

As you perform the merging process you'll form your own way of approaching it and it'll be different from mine, and from @davee's because we all have different experience and preferences for setting up and organizing our code.

A lot of it is just experience, looking at sample code and learning to identify what parts of it make it work and what parts display how it is working.

Never be afraid of making mistakes, you only ever LEARN by screwing something up. If it works first time you just move on but when it doesn't work you have to get more info and debug it and wrap your head around WHY it didn't work. That's what learning is.

@will 

        "you only ever LEARN by screwing something up."

Believe me, I've had a lot of learning in the past year or so. 😀 

Thanks Will

Lee

Hi @lee-g (& @will),

 I am only aiming at the most basic level ... from @will's comments, you may already be way ahead, but it is great to hear of your support for the principle.

Remember the "you only ever LEARN by screwing something up." also applies to trying to write explanations, so please be sympathetic if it happens to me. 🙄 🙄 

Best wishes, Dave

@davee Hi Will and Dave. Will, thanks for your encouragement and instructions. I will scrub back in and begin to look at the different parts of the puzzle you described. With time, (let's see, so it's 2024 now, so .......), it should start to come clearer to me, and I'll then be able to ask some questions as you suggested. 

Dave, once again, it's good to know you'll be out there "thinking". In the meantime, I'll be in my garage...."screwing things up" enough to put Lee and (everybody else) to shame!