Member postings for James Alford

Edited By James Alford on 22/03/2018 17:38:30

Martin:

I have had a look at the material with a magnifying glass. Rather than porosity, the structure seems to be more like very fine lines, like the grain in some cuts of beech wood.

BobH: thank you for the information about sines et all and the link to the web page. I have had a look at it and it has shed a lot of light on the tool. All I can say is thank goodness for modern calculators.

Regards,

James.

Edited By James Alford on 25/02/2018 20:09:21

Good morning.

This rule, which appears to be made of either bone or ivory, was amongst my gandfather's tools who was an engineer, designing tools. I have absolutely no idea what it is for or whether it is even a measuring rule at all.

I should welcome any information on it.

James.

Edited By James Alford on 25/02/2018 11:10:48

I bought a set of these a short while ago. I am not sure what thread they are, but they fitted with the rest of my connectors on my airline (both threads and fittings) which I bought from Screwfix, if I recall correctly. They seemed well made for the money and the swivel joint takes all strain out from the end of the hose when handling tools.

James

And I thought that I was only one who did this sort of thing.

Jon: your post has made me feel so much better. The number of times I seem to spend forever producing a pile of scrap and a piece that is barely usable, when so many people give the impression that everything always goes swimmingly, makes me think that I am not cut out for this hobby.

Your tale really reassures me.

James.

Dave,

Thank you for checking and confirming that it is possible to use t.pulse with an analogue pin. I have had another look at my code and found the problem.

I have a variable that is used to determine whether or not the hour LED should trigger. I copied the code used to trigger the LED on pin 11 each hour and renamed the variables to activate a different LED on pin A3. However, I missed one variable.

Once the hour LED has flashed, this variable prevents it from flashing again until the next hour. As the new sequence is after the hour sequence, the new code was being told not to run by this variable. Renaming it for the second routine solved it and it now functions as planned.

Regards,

James.

Edited By James Alford on 28/01/2018 17:33:47

Good afternoon.

I wonder whether anyone can advise before I go on a wild goose chase?

I have added another sequence of code to activate an additional pin once an hour. As I have run out of digital pins, I have used the analogue pin A3. I have copied and amended a block of code that I have already used to carry out the same function on a digital pin. It uses Dave's "tpulse" function to trigger the pin to light an LED.

The timing sequences all work correctly, but the LED does not light. As a test, I replaced the "tpulse" lines used to trigger the output with a simple delay. This lit the LED correctly at the appropriate intervals, confirming that the timing sequence and the circuitry are correct.

Before I go chasing the problem, does anyone know whether the "tpulse" function will actually work with an analogue pin? I have a niggling suspicion that it will not, but I am not quite sure why. Any help would be appreciated.

Thank you.

James.

Edited By James Alford on 28/01/2018 15:00:18

Good evening.

I am utterly bemused. This morning, I created a new sketch using the code that Marcus posted above, editing it to remove the smiley faces. I installed the relevant library and uploaded the programme to the board to test it: all went well and it worked, printing to the serial printer as designed.

This evening, out of curiosity, I tried compiling my original code again, having made no alterations to it. Much to my surprise, it compiled, loaded and ran perfectly.

I have absolutely no idea at all why this should have happened. The only thing that I can think of is that, somehow, installing the library for Marcus's code allowed mine to work. As the library names are different, this seems unlikely, but I really can not see what else it can be. No matter what; I shall be wary about further board and library updates.

I should just like to thank you all again for the detailed help with this problem.

Regards,

James.

Dave:

I had noticed that the SDA and SCL pins were labelled on the board, but did not know whether they still needed to be referenced.

I have also been coming around to the idea of starting the basic RTC code again to get that working and then reintroducing the additional structure, stage by stage. I shall try this over the next few days. Thank you for the offer of looking at my coding, should I get nowhere. I appreciate this, but shall try to resolve it myself before taking up more of your time.

I had thought that I used a RTC library from Northern Widget on github, but I am no longer quite sure. What puzzles me further is that I went back to the place where I initial found the RTC code that I am using and there is no reference there to any RTC library. The trouble is that I did this bit of coding several months ago and have forgotten the detail. A good example of why I should have added more notes to the source in the code........

Marcus:

Thank you for the RTC code. I shall copy this over and try it out to see whether I can then use this to get me going again.

Watch this space for an update in a day or two's time.

Regards,

James.

Edited By James Alford on 23/01/2018 07:08:50

Edited By James Alford on 23/01/2018 07:09:19

Edited By James Alford on 23/01/2018 07:10:02

Dave,

Thank you for the explanation, which makes sense and makes the problem both clearer and, perversely, more puzzling to me.

Firstly: I tried replacing DS3231 rtc(SDA, SCL); with DS3231 rtc( (const uint8_t) SDA, (const uint8_t) SCL); but received the same error message as before.

However, after reading your explanation, I read through the my code to try and find definitions of SDA, SCL or indeed anything else to do with the RTC. The only definitions or setting up that I can find are as below.

Near the top, before the void setup or void loop, but amongst the other definitions, was

DS3231 rtc(SDA, SCL); which is now replaced by DS3231 rtc( (const uint8_t) SDA, (const uint8_t) SCL);

A couple of lines down is this:

//define RTC address
#define DS3231_I2C_ADDRESS 0x68

There are no other references to the RTC or DS3231 that I can find, other than

// Initialize the rtc object
rtc.begin();

in void setup and a series of commands to read from the RTC for the display.

I thought that I had possibly managed to delete something vital without realising it, so checked a much earlier version of the sketch that was fully operational, but this was the same.

I am assuming that I need to add something to the code to specifically define the RTC. I shall have to have another go this evening after work.

Regards,

James.

#define DS3231_I2C_ADDRESS 0x68

Edited By James Alford on 22/01/2018 07:25:40

Dave,

Thank you for the suggestions. I have been playing with this, but to no avail so far. I have to confess that, to be honest, I do not really know what I am doing.

I have searched through the code for the SDA and SC definitions, but can find nothing there. I have added the "cast" code, but that has not worked either. The trouble is, though, that I am not sure quite what the bits const uint8_t really mean nor where I should place the "cast".

I shall carry on looking and playing............

James.

An irritating update.

I updated my Uno board and libraries following the prompts that came up when plugged it in this morning.

Now, on all versions of my programme, I get an error message on compiling saying:

error: no matching function for call to 'DS3231::DS3231(const uint8_t&, const uint8_t&'

DS3231 rtc(SDA, SCL);

The emoji is not my addition. I have no idea what has happened, but now need to try and unpick what is causing it..................

James.

Edited By James Alford on 21/01/2018 11:17:25

Good morning.

Thank you for the continued and additional suggestions.

Les: I did consider motors, cams and micro-switches initially and they are still a possibility for some elements of the finished design.

Neil and Ian: thank you for the information about solenoids and relays. I studied electromechanics at college for a few years when I was training to be a telephone exchange engineer, but it is scary just how little I can truly recall. Your posts have been fruitful refreshers.

Dave: I agree with you in that it is likely to be easier to refine the control of the device mechanically than with programming and I shall focus on that approach.

As mentioned, I do wish to complete my other main project before embarking on this at all, but below are some drawings of my ideas so far. It is quite small, the wheels being four inches in diameter: much more would exceed the capacity of my lathe. The base will house most of the solenoids, the Uno, circuitry and some batteries. The actuating arms pushing the wheels around will have a hinge and spring in them so that they can slide over the teeth when retracting for the next impulse. I am still trying to decide how best to display the time, but I am leaning towards a vertical, numbered ring on top of each wheel and a pointer; the time will be read vertically by reading off from the marker. I envisage a day of the week and a night time or day time display on the top. The whole thing, other than the base, will be placed within a clear tubular case.

Still, plenty of time to settle on a design that interests me enough to actually spend the time building it. I have designed two other clocks, but neither really engaged me anywhere as much as this has.

Regards,

James.

Edited By James Alford on 21/01/2018 09:55:09

Edited By James Alford on 21/01/2018 09:55:50

Edited By James Alford on 21/01/2018 09:57:34

Good morning.

Thank you for the replies and for the suggested code. My aim seems to be a lot harder to achieve that I had initially realised and I am wondering whether I should be better using a mechanical approach, as suggested. I had two reasons for wanting to use PWM: firstly, possibly mistakenly, I had thought that ramping up the power would save energy. However, if this is not the case, it lessens the point of the additional complexity of code. Secondly, it was to lessen the initial blow caused by the solenoid. However, this can be overcome, if no other way, by putting a firm rubber pad on the end of the actuator to absorb some of the impact.

I have gone down the route of solenoids, rather than stepper motors, simply because of familiarity. I agree that they might well prove rather noisy, though, and that stepper motors would be less intrusive. I shall have a look at the coding for these as I have never played with them before.

Regards,

James.