Author Topic: Pierre's 170W in 1600W out Looped Very impressive Build continued & moderated (Read 433528 times)

pmgr · « **Reply #360 on:** April 12, 2018, 05:43:22 AM »

Another thing to try is to plug in a wall-outlet power plug (9V or 12V) into the Arduino instead of depending on the laptop USB 5V. Maybe the thing needs more than 500mA of current when programming and the USB on your laptop is only providing 500mA max.
PmgR

r2fpl · « **Reply #361 on:** April 12, 2018, 07:23:35 AM »

gotoluc:

This is "normal" problem with arduino.

1.Check power from USB.
2.Add power to Arduino +5V from power supply.
3.Driver is corrupt, but see good in view. Must reinstall with this program: see attachments.
Check version arduino (if version china maybe driver still problem)

ad.3:
Option/List all devices
Select Arduino port from select bar
Press Replace Driver

If make 1,2,3 steps correct Arduino go to normal programme.

Is possible corrupt Arduino because changes fuse bit. Little possible but possible. You can save make DFU process but is very problematic for new users.

listener191 · « **Reply #362 on:** April 12, 2018, 10:12:17 AM »

I have noted that using pin mode on digital pin 1 is actually using the UART port bit TX1 used for USB communication.

Perhaps we should shift all 30/36 pins down one i.e. 2 to 31/37?

Regards

L192

TinselKoala · « **Reply #363 on:** April 12, 2018, 10:15:19 AM »

Quote from: gotoluc on April 12, 2018, 05:12:05 AM

Well, it looks like the Arduino board itself has a communication issue. The program is working but I can't upload any changes. See video.
So if someone can send me or buy me a replacement that would be great. Meanwhile I can test as is and need to know if I add a potentiometer (to vary frequency) is that part still in the program?

Fr. Eh bien, il semble que la carte Arduino elle-même a un problème de communication. Le programme fonctionne, mais je ne peux pas télécharger de modifications. Voir la vidéo
Donc si quelqu'un peut m'envoyer ou m'acheter un remplacement ce serait génial. En attendant je peux tester tel quel et j'ai besoin de savoir si j'ajoute un potentiomètre (pour faire varier la fréquence) cette partie est-elle encore dans le programme?

Video: https://youtu.be/8B2NOU0NaYw

Luc, have you tried unplugging all of the OUTPUT connections to the Mega and then reprogramming? It is barely possible that the current draw is too high during programming with all of the outputs capable of drawing current.

The fact that you've tried several laptops without success may mean that there is something wrong with the Mega itself, OR that there is something about the way you have it connected to the rest of the circuitry. Before you replace the Mega let's at least rule out the external connections.

More to follow:

TinselKoala · « **Reply #364 on:** April 12, 2018, 10:23:13 AM »

Quote from: pmgr on April 12, 2018, 05:27:00 AM

One more thing you should check is the serial port baud rate. You can change this under the device manager in Windows. I am not sure what the rate should be for the Arduino, but try the following rates:

9600, 14400, 19200, 28800, 38400, 57600, or 115200

It is extremely unlikely that this is the cause. Especially since Luc has checked different versions of Windows on different machines, and his friend used an Apple computer running OSX and still failed. I have never seen this port speed setting in Windows to have an effect on uploading to the board.

Quote

For the potentiometer, you can uncomment Pierre's old lines:

int y= analogRead(0); // transforme x en une valeur de 0 à 20 (millisecondes)
x= map(y,0,1000 ,1,100);

and then comment your x=50 line:
// x=5; //total loop delay is 20*x = 100ms. f=10Hz

The potentiometer has 3 leads. Two outer ones should be hooked up to GND and 5V and the center one should be hooked up to the analog 0 input.

Also, see: https://www.arduino.cc/reference/en/language/functions/analog-io/analogread/

PmgR

The ADC inputs of the Arduino return values between 0 (0 volts) and 1023 (5 volts, OR what is supplied to A_ref pin). So for full range of the pot setting the map() statement should go from 0 to 1023, not stop at 1000. Otherwise values of the pot when adjusted near the 5v end will give strange results.
Like this:
x= map(y,0,1023 ,1,100);

Also, in my previous code revisions I've shown where this statement goes for realtime speed control (don't have to finish one full loop before speed setting takes effect).

More follows:

TinselKoala · « **Reply #365 on:** April 12, 2018, 10:32:47 AM »

Quote from: stargate22 on April 12, 2018, 05:38:10 AM

Options;
1). Remove board / UN-plug completely from device and re-program.

I and others have also suggested this. It's a good idea before giving up totally on the Mega unit in use.

Quote

2).Add the following to the sketch....

void setup() {
// initialize serial communications at 9600 bps:
Serial.begin(9600);
}

It initializes the serial connection at 9600 bits per second. Both sides of the serial connection (i.e. the Arduino and your computer) need to be set to use the same speed serial connection in order to get any sort of intelligible data. If there's a mismatch between what the two systems think the speed is then the data will be garbled.

9600 bits per second is the default for the Arduino, and is perfectly adequate for the majority of users, but you could change it to other speeds: Serial.begin(57600) would set the Arduino to transmit at 57600 bits per second. You'd need to set whatever software you're using on your computer (like the Arduino IDE's serial monitor) to the same speed in order to see the data being sent.

As far as I can tell this use of the Serial communications system has nothing to do with uploading programs to the board. It enables serial communication to a serial monitor which can be accessed from the IDE, but then you have to send data to and from the serial monitor using write and read statements in the sketch. Serial comm statements also slow the program down quite a bit. You can certainly try this but I would be amazed if it made any difference to the main problem here.

Quote

3) Looks like board is running when you re-programed, which is fine, that can be done, however Pierre may have been correct in pointing out the "field" may interfere with the board ?

That's all I have to comment... : {

Again, I think this is not a likely cause. I've never encountered _magnetic_ interference that affected the Arduino. Electrical interference is something else though. I would worry about the USB cable picking up electrical noise from the system, and cleanliness of power supplied to the Arduino when the USB cable isn't in use.

By the way, the Arduino should NOT be powered through the +5v pin(s) unless you have absolutely stable regulated and filtered +5 volts to feed it. It is far better to supply +9 to +12 volts to the regular coaxial power jack so that the board's own VR circuitry can handle the power conditioning.

TinselKoala · « **Reply #366 on:** April 12, 2018, 10:38:57 AM »

Quote from: listener191 on April 12, 2018, 10:12:17 AM

I have noted that using pin mode on digital pin 1 is actually using the UART port bit TX1 used for USB communication.

Perhaps we should shift all 30/36 pins down one i.e. 2 to 31/37?

Regards

L192

I have mentioned this before, because I have occasionally had problems using digital pins 0 and 1 for certain purposes. So I tend to avoid them if possible. However I've tested versions of the sketch (my versions of other versions!) on my local Mega using Pin 1 and didn't see any problems, with either running or uploading. I would be surprised to find that the uploading problem is related to the use of Pin 1 in the sketch.

MichelM · « **Reply #367 on:** April 12, 2018, 10:39:55 AM »

Hello Luc,

in my opinion, the influence of the magnetic field is probably the cause of the problem.
The easiest way is to remove the magnetic field to transfer the program.
For that, maybe you just have to unplug the GND.

FR
à mon avis, l'influence du champ magnétique est probablement à l'origine du problème.
Le plus simple, est de supprimer le champ magnétique pour transférer le programme.
Pour cela, peut-être qu'il suffit de débrancher seulement la GND.

TinselKoala · « **Reply #368 on:** April 12, 2018, 10:43:02 AM »

I would still like to see the _exact_ sketch that Luc is now running (or trying to run) so that I can check the sketch for problems on my Mega. I have both Linux and Windows computers that I can use to check for uploading problems related to the sketch (although there are not likely to be any.)

But please--- do post the exact sketch that is being used currently so that I can review it.

T-1000 · « **Reply #369 on:** April 12, 2018, 10:43:55 AM »

Quote from: MichelM on April 12, 2018, 10:39:55 AM

in my opinion, the influence of the magnetic field is probably the cause of the problem.

There is no magnetic field when the program is not running. From Luc's video it clearly shows programmer interface issue (damaged usb/serial port or drivers)...

And when it iwill be running there are lots of ways to shield magnetic field from the Arduino.

Cheers!

TinselKoala · « **Reply #370 on:** April 12, 2018, 10:49:22 AM »

Quote from: MichelM on April 12, 2018, 10:39:55 AM

Hello Luc,

in my opinion, the influence of the magnetic field is probably the cause of the problem.
The easiest way is to remove the magnetic field to transfer the program.
For that, maybe you just have to unplug the GND.

FR
à mon avis, l'influence du champ magnétique est probablement à l'origine du problème.
Le plus simple, est de supprimer le champ magnétique pour transférer le programme.
Pour cela, peut-être qu'il suffit de débrancher seulement la GND.

I disagree. I don't think that the magnetic field could be causing the problem. At least magnetic fields have never caused any problems with my own Arduinos. (I use UNOs, Megas, and ProMinis for many projects.)

However I _do_ think it is possible that something in the external circuitry and/or power supply may be causing the problem. So I'd like to see Luc try programming the Mega with it disconnected totally from the external circuitry. Then if the program uploads properly, the Mega can be reconnected to the external circuits and we can see what happens then. If the program will still not upload even with nothing connected to the Mega except the programming USB cable... AND if I can get the sketch to upload properly to my own Mega using Windows here at my lab... then we may suspect a hardware problem with Luc's Mega board.

listener191 · « **Reply #371 on:** April 12, 2018, 11:57:12 AM »

The untested code that I listed for 30 slots, would have required OR gates on the L298N enable inputs, otherwise there would be Output pin clashes for the enable lines.

I now have 5 unique sequences use for enable that avoid that issue.

I just mention this in case this code was used by anybody.

Regards

L192

r2fpl · « **Reply #372 on:** April 12, 2018, 12:18:36 PM »

Quote from: listener191 on April 12, 2018, 10:12:17 AM

I have noted that using pin mode on digital pin 1 is actually using the UART port bit TX1 used for USB communication.

Perhaps we should shift all 30/36 pins down one i.e. 2 to 31/37?

Regards

L192

I agree too !

dole · « **Reply #373 on:** April 12, 2018, 12:38:36 PM »

Definitely TX/RX problem (pin 0,1)
Solution:
Push reset baton and upload immediately or disconnect/connect and immediately upload
But probably same problem will still persist next time.
Do not use 0,1

d.

listener191 · « **Reply #374 on:** April 12, 2018, 12:55:25 PM »

Quote from: Slider2732 on April 12, 2018, 12:02:21 AM

Yeah, it's just the port by the looks of it.
Nothing wrong with the code.
At the bottom of your screen it shows you've selected the right type of Arduino and indeed it compiles fine. The only thing different would be the Port.
Click 'Tools', then 'Port' and see what it says there...you should only have 1 or 2 to select from and it seems like it's picking the wrong one as default.

Another way, is to unplug the Arduino USB cable and plug it back in, the other port will then be selected. At least here on Linux Mint it does, from USB0 to USB1 even if it's the same device being plugged in and out.

With the Chinese 2560 boards USB is on Com 4 not 1, as you would expect from an original.

L192

News:

User Menu

Author Topic: Pierre's 170W in 1600W out Looped Very impressive Build continued & moderated (Read 433528 times)

pmgr

Re: Pierre's 170W in 1600W out Looped Very impressive Build continued & moderated

r2fpl

Re: Pierre's 170W in 1600W out Looped Very impressive Build continued & moderated

listener191

Re: Pierre's 170W in 1600W out Looped Very impressive Build continued & moderated

TinselKoala

Re: Pierre's 170W in 1600W out Looped Very impressive Build continued & moderated

TinselKoala

Re: Pierre's 170W in 1600W out Looped Very impressive Build continued & moderated

TinselKoala

Re: Pierre's 170W in 1600W out Looped Very impressive Build continued & moderated

TinselKoala

Re: Pierre's 170W in 1600W out Looped Very impressive Build continued & moderated

MichelM

Re: Pierre's 170W in 1600W out Looped Very impressive Build continued & moderated

TinselKoala

Re: Pierre's 170W in 1600W out Looped Very impressive Build continued & moderated

T-1000

Re: Pierre's 170W in 1600W out Looped Very impressive Build continued & moderated

TinselKoala

Re: Pierre's 170W in 1600W out Looped Very impressive Build continued & moderated

listener191

Re: Pierre's 170W in 1600W out Looped Very impressive Build continued & moderated

r2fpl

Re: Pierre's 170W in 1600W out Looped Very impressive Build continued & moderated

dole

Re: Pierre's 170W in 1600W out Looped Very impressive Build continued & moderated

listener191

Re: Pierre's 170W in 1600W out Looped Very impressive Build continued & moderated