My Motors got me to Tap into Radiant Energy

[Ufopolitics]

Channel1 and 4?

@ Garry
Got it up and running on my two brush. Running on M5, she starts slow and comes up to max and motor speed oscillates up and down. Where do I go from there?
Also motor stops whenever any input is entered and then returns to previous speed. I sent you a PM earlier today and it sounds what I stated is possibly the case here.
Besides motor speed being controlled by Battery volts, is there any method I missed to control speed here.
Overall my impression of your program is pure talent. Some issues will always arise and I know you will handle them in due time. We are blessed to now have you on the active team.
Dana

Hey Dana,

Could it be possible that you have Two Channels out of Sequence, or too spaced apart...say 1 and 4...that's related to your Two Brush Motor Speed Oscillating...just thinking of a "probable cause" within the hook up...

A Two Brush Set Up...getting a too wide space between firing times...will definitively oscillate.

Maybe not a possibility to make that mistake there...don't know...You two Guys are the Ones running "The Show" here.

And yes, it is a blessing to have Gerry here...I believe this Configuration will render Good Results.

Warm Regards


Ufopolitics

[GChilders]

motor stopping with new program

@Dana

Yes and I think I know what the problem is for all three conditions that you are speaking of. 1. The motor starts out slow. This is a simple fix. I thought that we could ramp up the speed in 200 rpm increments this may be unnecessary. Let me show you how to solve all three problems. The motor stopping when you change modes is most probably because of a 250 millisecond delay in the serial transmission. I read that this delay is necessary but I don't think it needs to be nearly this long. here is where you will find it in the main loop
void loop() {
//have the arduino wait until it receives a message
if (Serial.available() > 0){
// Read serial input
while(Serial.available() > 0){
msg += char(Serial.read());
delay(250); change this to 25 milliseconds and see if the problem is solved. The problem may manifest it self in the serial monitor echo being broken instead of echoing the command. in other words motor started will break up into different lines.

a little further down there is this line in the serial commands

else if (msg == "Start"){
boolianMotorSpeedRamp = 1;
motorSpeedRamp(0, 65);
Serial.println("Motor Started");
}

try changing the number 0 to 1 if it still starts too slowly go to 2 and so on until you get a start that seems natural and easy. Then post about the change.

the motor oscillating has me wondering. Is it moving past 3600 rpm? and then coming back down to 3600 rpm or is it struggling to get to 3600 rpm and then moving back down? The second number that you see above is the
duty cycle and actually may be either too high or too low. The number needs to be lowered if it is overshooting the mark and coming back down, it needs to be raised if it is struggling to get to 3600 and then moves down. Let me know.

Cheers

Garry

[prochiro]

Hello Garry
The first two now I can handle after seeing your examples. Let me change those and see after that what happens first.
Thanks
Dana

[prochiro]

Hello Garry
The first question is solved. I changed it to 25 and there was still a small burp in motor speed so changed it to 15 and it is seamless operation.
Too late for the rest and I will put a scope of it in the morning to see what is going on there.
Dana

[CalebMcanelly]

A teacher, or the prison, more and more ares are considering the legal use of cell phone jammers, it has been a necessity of our daily life, I have got one for my family. so if you want to get one, you can go and visit it for more details. share with you!

[JohnStone]

@Garry,
thanks for your contribution. It is amazing how you master codes. You arrived this forum just in the correct moment in order to give it a new kick - just in time
I can not access dropbox from my working place but I am sure your tut is is professional as well.

I2C:
Because of the existance of the clock and Arduino being the master there is no complicated timing to obey. Standard clock speed is up to 100Khz and will go for some slaves beyond 400Khz. Only the slowest slave is the restiriction. And the master does not need to clock on a regular basis.
As I2c has no inherent data check we need to take some provisions (1) Cables shall be shielded and low capacitance (CAT5 pach cables -> cheap and superiour) (2) SW shall check for values out of range.
Opto isolation is possible if requested.

BT:
As our setup spreads a lot of radio disturbance and GND currents it will be critical for PCs. Some of us will not dare to connect their sole PC. As far as I know, those cheap BT modules can be run as COM I/F like USB. I feel tehre is not more to it than writgn some few code lines. Do you agree?


Dashboard:
Yes I agree an LCD is very restricted. It is a great help if you priovide a dashboard on PC level. But we do not want to load you with excessive tasks. May I point you to the SW tool Profilab Expert.

The serial protocol is programable and will talk to Arduino.
Additionally lots of measurement tools can be added directly to PC.

I own some VA18B with opto isloated USB/serial link.
It is not remote controllable but transmits 3 times a second its values (those adjusted by the local dial)
The message is: Our Arduino is not supposed to perform ALL taks.

I own Profilab expert and am willing to contribute taylored run time versions as dashboard to Arduno. Hence my suggestion is: you decide how much dashboard you want to provide and what complecity. Dedicated dashboards for certain test shall be done by Profilab.

Once again: I want you all to know where our playground can be - we chose the limits.
JS

[Cornboy 555]

Rockers.

John Stone, Garry Childers, and Dana, You Guys ROCK,

Thank You soooo Much.

Warm Regards Cornboy.

[JohnStone]

John Stone, Garry Childers, and Dana, You Guys ROCK,

Thank You soooo Much.

Warm Regards Cornboy.

Thanks for appreciation!
We live in an amazing time.
When I startet my career first microprocessors arose (6505 from Rockwell). A sample board was about 1K bucks. An ethernet I/F was a 19" x 19" PCB built with basic logic ICs. Semiconductors were built from structures between gigantic 3...5 micron. (now "wires" in chips are paved from 50 atoms in width)
At that former times it occured sometimes that insects lived on those warm boards - therefore the term "buck" for a malfunction.
Later we run nurse call systems for whole hospitals from a single micro like 1/3 Arduino performance.

And now anybody can buy a processor as system for some bucks, we have plenty of choices and the problem is more to choose the right ones.
I'd like to get you all aware of these facts in order to express the real needs first. Electronic and programing is not our goal but our tool. Therefore we need to choose the right components in order to focus an motor performance.

Cornboy, obviously you never were touched by tinkering with electronics. That is completely OK. Guys like you need a tool to run MAG3. OK - you are our reference customer and the tools we discuss here shall be your tools.
JS

[prochiro]

@Garry
Yes (15) is good for the first question and it will work just fine with 10 also.
I was testing with 2 brush setup and as usual starting with 12 volts. While in M5 mode, nothing seemed to help although this revving did not occur in any other mode. Now I did not un-comment the large speed control section. I went to 24 volts and the revving stopped but then the ramp up was gone. Maybe all this could be explained by the lack of RPM sensor installed? Anyway I'll keep checking out other parts of program. Did you find a way to convert the strings you were talking about.
Good Work
Dana

[GChilders]

@Dana
first,
comment out the rpm check if you have not got a hall effect sensor, or infrared send receive module for tracking rpms connected to your interrupt0 pin.

this could stall out the program as it looks for information that should have a value and defaults to zeros as there will be no information updated to the rpm array without the action of the update.

do you have a handheld infrared tachometer? if so take the rpm readings if you would to let me know what rpm your motor is reaching I am blind without this information. So you changed the 65 to 70 then to 75 and then to 80 and it still oscillates?

and when you say it oscillates I take that to mean it goes up in rpm and then down in rpm up in rpm and down in rpm??

and mode 4 does not do this??

so it would not be because of the pulsing

were you able to get the motor to start at a faster speed and what setting did you end up with for the first argument, instead of 0 what did you put in.

awaiting your answer,

cheers

Garry

[Hitby13kw]

@Dana, Thanks for posting your test results with Garry's new code, it inspired me to give it a go . . . .

@Garry, Made the code changes you already discussed with Dana, and one additional line
arrPWMPins[1] = 5; // Original Value was 10 ~ changed to 5 so would not have to remake interface cable hardware

I felt we were good to go, so after obtaining the Klein CL2000 True RMS meter UFO recommended (Thanks for the Tip Bro)
we redid all the tests using the QuadBlink code and then did them again with RMCV0.0.1 – all test were performed in Mode5, with no load even tried to advanced and retarded the timing a few times in 10 degree steps (saw fluctuations in current when hitting the return key but then it would return – perhaps this is because we had no load ~ or as Dana suggested we have no sensors connected yet) As you will see from the table that follows for a given voltage input the current was less with the new code, but the RPM was also lower, so first thought is did we gain anything . .. . me thinks we did because I see larger spikes coming off the coils ~ didn’t do an extended run but that should mean that the batteries charging on reflected energy will do so faster – time will tell (also noted because the frequency was higher the FETs ran a bit hotter and the motor didn’t start to turn until after 6V - (was 2V))

Quadblink

Volts Amps RPM

30 - 6.74 - 1394
40 - 7.05 - 1914
50 - 8.90 - 2319
60 - 11.60 - 2753
70 - 14.65 - 3165
80 - 18.66 - 3633
90 - 23.58 - 4040

RadiantMotorControlVersion0.0.1

30 - 5.38 - 1250
40 - 5.88 - 1749
50 - 8.29 - 2050
60 - 10.73 - 2300
70 - 11.24 - 2840
80 - 13.90 - 3120
90 - 16.60 - 3440

Hitby13kw

[prochiro]

Hitby
Do this

void loop() {
//have the arduino wait until it receives a message
if (Serial.available() > 0){
// Read serial input
while(Serial.available() > 0){
msg += char(Serial.read());
delay(250);// change this 250 to 15 , will stop fluctuations .

Dana

[Cornboy 555]

Supply.

Thanks for your results Hitby, , was your motor powered by batteries, or from Grid supply?

Regards Cornboy.

[GChilders]

rmc timing

@all
I noticed that both Dana and Hitby13kw have attempted to use the timing commands. This is an idea that I was working on but has absolutely no effect on the motor as there is no connection in code other than to echo back that the timing has changed. No effect at all. It was an oversight on my part to leave those commands there. Sorry for the illusion that timing had been worked into the program. Ignore those commands they have no effect.

Every one seems to be very excited and changing things in the program. Hopefully you fully understand how the program works before you make changes. It can be dangerous to you and your machinery if you do not. There are many interrelated pieces and a change in one area can effect changes in other areas. Just a word of caution. Make sure that you truly understand the ramifications of your changes before making them. Please copy and paste the changes that you make in a pm to me so that I can verify that the changes that you made are solving the problem or are creating the problem.

@hitby
it seems that your rpms are extremely low. when you say that you made the changes that I talked to Dana about could you please be more specific than that, please copy all code that you have changed after changing it and paste it into a pm to me so that I can verify that the changes are correctly done and are not going to affect a part of the code that you were not aware of. I would prefer that. I do not want to be a buzz kill or for you to think that you are incapable of making changes but at this point I do not know the coding skills of the individuals in the forum very well and it takes a while to fully comprehend the code, especially if you are at a fairly basic skill level. I trust that you will not be offended by this but I have your safety in mind.

below are the only changes Dana and I have discussed

void loop() {
//have the arduino wait until it receives a message
if (Serial.available() > 0){
// Read serial input
while(Serial.available() > 0){
msg += char(Serial.read());
delay(250); change this to 25 milliseconds and see if the problem is solved. The problem may manifest it self in the serial monitor echo being broken instead of echoing the command. in other words motor started will break up into different lines. we changed this to 15 milliseconds instead of 25

a little further down there is this line in the serial commands

else if (msg == "Start"){
boolianMotorSpeedRamp = 1;


motorSpeedRamp(0, 65); what do you have here, copy and paste please?


Serial.println("Motor Started");

}

This is the most critical area to change for smooth start ups and I have yet to get a single piece of solid feed back from any on what they have done in this area please give me this information words only cloud the issue if they are not framed in the right context.

Thank you for all the kind words and accolades but there is a lot of work to be done and this will speed things along.

you should have raised the 65 to new number and rechecked the rpms if you have not then please raise it to 90 and do another run to see if the rpms have come up to where they need to be. We need to trim the motor speed now while it is not under load that is step one people get the rpms up to 3600 plus anything less is unacceptable.

cheers,

Garry

[Ufopolitics]

Flow Chart...

Hello Guys,

I Highly recommend to transfer all your Data into Flow Charts...it will help you to "see" what's going on...from a Graphic point of view.

[IMG][/IMG]

I made this Flow Chart according to Hitby Data...

When we see both curves at both charts...we see almost same Issue...

GChilders Radiant Motor Control needs to be "Stretched Out" ...to obtain a similar or even better "smooth" flow result, as Quad Blink does....and that eventually will create same effect on amplifying Speed/Reducing Amp Draw...

If You notice the "Area of Conflict" comprehend same close points...

Create the "Ideal Flow Curve" (I will do it tomorrow...forgot to, and is too late) to be Your Guide to approach...

And really...looking at RPM's reaching range required for Generator Head, or 3600 [look at 80 Volt Feed for both Systems]......we notice that Gerry's is only behind by 480 RPM's...which is not much...

Now, Gerry's Codes have much more Parameters to "Play" with, therefore, is more complicated to Set Up...but am sure as you get the "Name of the Game"...it will be an "Easy Piece" to Adjust...

At the same token...the fact of having more parameters...basically fragmenting/dividing the On Times (Duty), creates this starting situations...

Quad Blink have just one Big "On Time" Pulse...reason why it could turn Motor at lower voltages...(2.0 Volts)
Gerry's have same On Time but divided through Time into smaller pulses/On Times...so the "juices" that reach every Coil per same unit of time is Too Small to move Coils...like I wrote before...not enough time for a strong magnetic field to develop.

But am very sure everything could be worked out and be very, very efficient.

If You could see the "MAX DRIVE" for a Motor...would notice that, if we make even more number of Gates/Brushes...and increase Voltage...Amps would be reduced even more...Now, Gerry's codes are doing just that without going into structural changes...

An "Ideal" Pulse Sequence would be to start with stronger magnetic fields on the core, Filling those coils with longer On Times...till reaching a steady RPM's/Breaking Inertia Forces....then start fragmenting it for shorter times On...and Higher Voltages...rendering much less Amp draw...This is the Basic Game here Guys...


You guys are doing a Beautiful Work!!...Awesome...and extremely interesting!


Kind regards to all


Ufopolitics