Closed Mike58501 closed 7 years ago
I am thankful for the "within scope" support that I did get on the above project. A trust worthy electrical engineer gave me a "heads up" on potential noise from leaving the usb from the laptop on the board during testing. Also he gave me a "heads up" on using all three of the ground connections as a "star" arrangement instead of just combining all three DC grounds ... 12vdc gnd, external 5vdc gnd, & the onboard SparkFun Rredboard UNO clone's own 5vdc gnd. I did leave out trying to control all "concurrent time remaining" on the LCD which solved the "memory shortage" issue. The prototype is now testing without error & will hopefully continue to do so. Time will tell. On that note I will be closing this issue ... with the understanding that anybody can re-open it later.
@Mike58501 Just curious, what was the conclusion about the GND connections? Did he suggest that you keep them separate as long as you can, or on the opposite that you combine them as early as possible?
rawtaz,
I may have to press him further. It is my understanding that the board internally combines the grounds but something mitigates the noise between that could otherwise happen if the grounds were combined on the outside. Since this project will go into what could be a much noisier environment than I could come up with on my two evolving due diligence prototypes ... time will tell if all noise is 100% solved. I did drop all of Tinkerspy's Time Machine onChange time countdowns within the code ... possibly caused by some code capability being not within my range of capability.
Hi Tinkerspy,
Hopefully straightforward for an expert ... 4 questions:
When external contacts on SPDT relay make or break with the Arduino Ground (com) are read with your Automaton Process ... I am seeing that your Digital Machine (if one can get by with it) saves memory over your Button Machine.
I have a total of eight separate digital machines that are basically just reading a ground signal or loss of ground signal with some control of duration of the time the make or break change is on. To prevent electrical noise problems I am using input pullup mode on all of those pins used with your Digital Machine. Almost 100% using just ground signals.
Can you explain if changing some of your "true" to "false" can ever be helpful or do anything at all in the way the digital machine behaves.
So far I am setting pinModes & declaring them as integers etc of all eight of those above pins used with my own Automaton Machine in the ino file & the cpp & hpp files of the newly created custom machine. Could it be that a person can be overly cautious so all three files would have those 8 pinMode settings & int declarations. Could that cause more use of very scarce SRAM memory?
It seems like I might be just using the Custom Machine only for receiving push changes from your Digital Machine & with the Acceptor Machine's serial output & serial buffer held to control the moving to specific states for specific ENT outputs. Which then runs relays in a timely way & change them back & so the relays shut off by the specific action(s) usually on the specific state's EXT action. Does that mean that there is no need for a "push connector" on my Custom Machine since it seem like it really does not push anything to other machines but just receives "pushes" from the other mentioned machines (mainly your digital machines)? Maybe I am wasting a bit of SRAM by adding a push connector in my Custom Machine in your machine template creator or does it need to be there to receive pushes also???
Do I only need to declare the output pins in cpp & hpp as long as the changes in digitalWrite is only occurring within the table's ENTs & EXTs actions? Would they be declared as PRIVATE along with the event timers being declared PRIVATE?
Thanks again.