Electronics Schematic Labelling does not match software pin mapping

Question

Electronics Schematic Labelling does not match software pin mapping

Closed this issue 7 years ago · 15 comments

The Electronics Schematic for the Maslow CNC Motor Shield has different Arduino Pin Mapping Labels from the latest revision of the software for V1.2 of the PCB which is the closest match.

The inconsistencies are as follow and should be looked at for completeness
The discrepancies are as follows

Software mapping PCB Revision 1.2

Software shows AUX ports are AUX1 = 17, AUX2 = 16, AUX 3=15, AUX4=14
Electronics Schematic shows AUX1=14, AUX 2=15, AUX3=16, AUX4 = 17
I am not sure if the schematic is correct or the software pin mapping as I am not sure anyone uses these but this should be looked into

Software mapping PCB Revision 1.2

Software Mapping Encoder1A=20, Encoder1B=21, Encoder2A=19, Encoder2B=18 , Encoder3A=2, Encoder3B=3
Electronics Schematic shows Encoder1A=18, Encoder1B=19, Encoder2A=21, Encoder2B=20 , Encoder3A=3, Encoder3B=2

Given that the system is working for other users the software mapping must be correct and the electronics schematic incorrect. This should be looked into

Answer 1 · 2018-01-10T18:50:02.000Z

The schematic has been different from the silkscreen and software since the beta days. I'll open a PR to change the v1.2 schematic and replace the .jpg of the schematic. Do we want signal, ground and Vcc indicators next to the rows of pins as well (or should that be a separate PR)?

Answer 2 · 2018-01-10T19:10:44.000Z

I think one PR would be OK. Doing version control on the PCB files is so dicey anyway that I vote less pull requests is better to avoid conflicts

Answer 3 · 2018-01-11T00:46:57.000Z

Thanks for your Reply Scott, The Schematic in its current form is perfect the pin mapping just need to match the current version of the software and hardware revision as noted. The reason I requested the change is that I am documenting the Maslow Building Blocks so that others trying to understand the code can make a connection with the hardware. It would also be helpful to indicate which revision number of the hardware the schematic represents and putting in the Signal Ground and Vcc indicators next to the row of pins is a great idea. I think we can do all of that in the one PR Currently the Wiki shows Software pin mappings up to version 1.2 of the Motor Shield hardware.

…

On Thu, Jan 11, 2018 at 4:50 AM, Scott Smith ***@***.***> wrote: The schematic has been different from the silkscreen and software since the beta days. I'll open a PR to change the v1.2 schematic and replace the .jpg of the schematic. Do we want signal, ground and Vcc indicators nest to the rows of pins as well (or should that be a separate PR)? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#36 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AgmKOPFQrmNOxgmfryRYM1eMtEb4TwFbks5tJQZbgaJpZM4RCubg> .

-- stuartnicole.richards@gmail.com

Answer 4 · 2018-01-11T05:22:35.000Z

Here is a modified schematic with the nets renamed to match the silkscreen and the firmware. Note that I've moved J2, J3, J4 and J5 around to keep the AUX pin names in order as well:

and the companion board layout with labels for the AUX GND and Vcc:

Let me know if this satisfies the issue, if so I'll put in a PR wit these changes.

Answer 5 · 2018-01-11T05:41:05.000Z

Scott, I have checked the schematic and there is still an issue with the mappings for The Encoder Channels A & B. If you look at System.cpp and check the mappings for version 1.2 of the hardware board the mappings should be as follows else if(pcbVersion == 2){ //PCB v1.2 Detected //MP1 - Right Motor ENCODER1A = 20; // INPUT ENCODER1B = 21; // INPUT IN1 = 4; // OUTPUT IN2 = 6; // OUTPUT ENA = 5; // PWM //MP2 - Z-axis ENCODER2A = 19; // INPUT ENCODER2B = 18; // INPUT IN3 = 7; // OUTPUT IN4 = 9; // OUTPUT ENB = 8; // PWM //MP3 - Left Motor ENCODER3A = 2; // INPUT ENCODER3B = 3; // INPUT IN5 = 11; // OUTPUT IN6 = 12; // OUTPUT ENC = 10; // PWM } Kind Regards Stuart

…

On Thu, Jan 11, 2018 at 3:22 PM, Scott Smith ***@***.***> wrote: Here is a modified schematic with the nets renamed to match the silkscreen and the firmware. Note that I've moved J2, J3, J4 and J5 around to keep the AUX pin names in order as well: [image: powerdistributionschematic-pr] <https://user-images.githubusercontent.com/1851315/34809537-63fb47de-f64a-11e7-8609-b73f5a6513c9.png> and the companion board layout with labels for the AUX GND and Vcc: [image: powerdistributionboardlayout-pr2] <https://user-images.githubusercontent.com/1851315/34809767-01c4654e-f64c-11e7-9fa2-9ee7a9f59d63.png> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#36 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AgmKOMJ7YstSO8GTn1zq-2W7pQ7hPPzoks5tJZqcgaJpZM4RCubg> .

-- stuartnicole.richards@gmail.com

Answer 6 · 2018-01-11T07:41:22.000Z

You're certainly right, the encoder signal names for motors 1 & 2 were wrong. I've re-done the IN__ names for Motors 1&2.
Thanks for catching this too. Here's the result:

Answer 7 · 2018-01-11T09:45:38.000Z

Scott, Almost there. The pin mapping for Encoder 3A and 3B need to be swapped as 3A is pin 2 and 3B is pin 3. I was also looking at the data sheet for the H-Bridge and note that the Ena is on Pin 6 and Enb on Pin 11 as per the diagram below. The schematic has Ena on pin 5 of the Arduino which is connected into the H-Bridge Driver on Enable_A however it is labelled with Pin 8 so this does not look correct. Also Enb is on pin 8 of the arduino which is then connected into the H-Bridge Driver on Enable_B however it is labelled Pin 14 so this does not look correct either. From the Firmware Arduino Pin 5 (ENA) is actually connected to pin 6 of the H-Bridge Driver Chip Arduino Pin 8 (ENB) is actually connected to pin 11 of the H-Bridge Driver Chip Unless I am missing something the pin mappings on the H-Bridge Driver Schematic don't look correct [image: Inline image 1] Kind Regards Stuart

…

On Thu, Jan 11, 2018 at 5:41 PM, Scott Smith ***@***.***> wrote: You're certainly right, the encoder signal names for motors 1 & 2 were wrong. I've re-done the IN__ names for Motors 1&2. Thanks for catching this too. Here's the result: [image: powerdistributionschematic-pr4] <https://user-images.githubusercontent.com/1851315/34813676-bc6ad58c-f65f-11e7-9486-4173b076fd83.png> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#36 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AgmKOFto7eSoomP8aVm8bgE_vNWx17eWks5tJbsjgaJpZM4RCubg> .

-- stuartnicole.richards@gmail.com

Answer 8 · 2018-01-11T19:55:01.000Z

I've swapped INC3A/INC3B on the schematic.
The diagram you mention didn't make it into the comment, but it sounds like you're quoting pin numbers for the 'Multiwatt15' package L298N or L298HN; we're using the 'PowerSO20' package, L298P.

Is that the issue?

Answer 9 · 2018-01-11T19:58:06.000Z

Here's the schematic that addresses INC3A/INC3B:

Answer 10 · 2018-01-12T01:02:45.000Z

Apologies Scott you are 100% correct. The pinouts in the Schematic were for the Multiwatt 15 and not the PowerSO20. Thanks for making those amendments. Kind Regards Stuart

…

On Fri, Jan 12, 2018 at 5:55 AM, Scott Smith ***@***.***> wrote: I've swapped INC3A/INC3B on the schematic. The diagram you mention didn't make it into the comment, but it sounds like you're quoting pin numbers for the 'Multiwatt15' package L298N or L298HN; we're using the 'PowerSO20' package, L298P. [image: screen shot 2018-01-11 at 11 53 12 am] <https://user-images.githubusercontent.com/1851315/34844361-0f0bfc1a-f6c6-11e7-8c84-c3e1731f05ec.jpg> Is that the issue? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#36 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AgmKOPaH8C2WlePMmw60LGSxGmaXf-Kvks5tJmcWgaJpZM4RCubg> .

-- stuartnicole.richards@gmail.com

Answer 11 · 2018-01-12T01:04:01.000Z

That's Ok, thanks for going into the files in such depth. Is the Schematic ready for a PR, then?

Answer 12 · 2018-01-12T03:43:04.000Z

Yes Scott the Schematic is ready for PR. Kind Regards Stuart

…

On Fri, Jan 12, 2018 at 11:04 AM, Scott Smith ***@***.***> wrote: That's Ok, thanks for going into the files in such depth. Is the Schematic ready for a PR, then? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#36 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AgmKOG2S0Pkx2i6n0OMRR96bQkCcT3Yhks5tJq-CgaJpZM4RCubg> .

-- stuartnicole.richards@gmail.com

Answer 13 · 2018-01-13T01:44:02.000Z

This was addressed in PR#42 - is it Ok to close this?

Answer 14 · 2018-01-13T01:52:45.000Z

Yes, I believe so. Well taken care of 👍 👍 💯

Answer 15 · 2018-01-14T07:45:35.000Z

Thanks very much for that Scott. Kind Regards Stuart

…

On Sat, Jan 13, 2018 at 11:56 AM, Scott Smith ***@***.***> wrote: Closed #36 <#36>. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#36 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AgmKOIK5WH_tFomDnlAqyUYZ1r6j8GVfks5tKA00gaJpZM4RCubg> .

-- stuartnicole.richards@gmail.com