MGP
LDmicro user.
Op donderdag 20 juni 2024 15:00:47 schreef trix:
[...]
wat bedoel je met een aparte controller ?
edit: voor de duidelijkheid ik gebruik geen raspberry pi maar een raspberry pi pico (dat is al een micro controller)
Een controller die enkel de motordriver stuurt, die ook alle start en stops controleert, die elke 100stappen een puls geeft aan de RPI die de communicatie voor zijn rekening neemt (met wie of wat?), dus geen seriele communicatie tussen deze motorcontroller en de RPI, zuiver IO's gebruiken.
Natuurlijk heb ik geen overzicht van wat je van plan bent, misschien sla ik de bal volledig mis.
even voor mijn beeldvorming: met RPI bedoel je toch de raspberry PI en niet de raspberry pi pico ?
benleentje
Golden Member
Een controller die enkel de motordriver stuurt, die ook alle start en stops controleert, die elke 100stappen een puls geeft aan de RPI
Volgens mij heeft de RP2020 al dit ingebouwd. Het heeft in ieder geval een vrij uitgebreide io subsysteem dat veel taken op zich kan nemen.
MGP
LDmicro user.
Op donderdag 20 juni 2024 17:02:00 schreef trix:
even voor mijn beeldvorming: met RPI bedoel je toch de raspberry PI en niet de raspberry pi pico ?
De controller van de motordriver kan ook een atmel, pic, pico zijn, want ik lees ergens anders dat je data wilt verwerken, doe dat dan met een RPI, of dat nu een PI, PI pico of RP2020 is speelt geen rol, deze laatste moet zich dan niet aantrekken van de motor, enkel toestemming geven voor start/stop of andere werken.
Dit maakt het ook veel makkelijker om aanpassingen te doen aan het systeem.
ah zo 
het bewegen van de steppers (8 stuks) en het verwerken v/d data gaat niet tegelijk. met uitzondering van 1 beweging met constante snelheid waarvan bij iedere 100 pulsen een bericht over de UART moet worden verzonden (dit is waar de eigenlijke vraag over ging).
MGP
LDmicro user.
Dat komt mijn eerste vraag weer in beeld, wat moet die motorcontroller elke 100 pulsen dan verzenden? hij stuurt enkel de motor, wat anders dan de stappen kan hij dan verzenden?
fatbeard
Honourable Member
Een goed begin is geen excuus voor half werk; goed gereedschap trouwens ook niet. Niets is ooit onmogelijk voor hen die het niet hoeven te doen.
En wéér lees ik de topictitel verkeerd als "trix's grote MontyPython topic" ...
Op donderdag 20 juni 2024 17:39:17 schreef MGP:
Dat komt mijn eerste vraag weer in beeld, wat moet die motorcontroller elke 100 pulsen dan verzenden? hij stuurt enkel de motor, wat anders dan de stappen kan hij dan verzenden?
ik heb hem er eens bij gezocht:
Op donderdag 20 juni 2024 08:26:37 schreef MGP:
Ik zat eens mee te lezen en vroeg mij af welke 3 bytes er moeten verzonden worden, is dat de positie van de wagen na elke 100pulsen?
en zo geantwoord
Op donderdag 20 juni 2024 10:38:37 schreef trix:
1e = adres byte
2e = do your scan byte
3e = stop byte
dus niet de positie v/d wagen 
MGP
LDmicro user.
Op donderdag 20 juni 2024 18:32:14 schreef trix:
...
dus niet de positie v/d wagen
Wat dan wel? er is niks anders als je enkel de motor(en) bestuurt.
Maargoed ik zie het geheel niet en we begrijpen elkaar niet zo goed.
Ik vermoed ook dat je al heel wat andere toepassingen heb draaien waar je niets wilt aan veranderen, je volste recht om het anders aan te pakken.
Op donderdag 20 juni 2024 18:44:18 schreef MGP:
[...]
Maargoed ik zie het geheel niet.
dat voornamelijk
en dat is hier ook vaak het probleem. Het is allemaal uiterst geheim en je komt steeds met een hele specifieke vraag, maar omdat er geen overzicht is van heel je systeem, is goed advies ook lastig. Als je daarbij ook nog vol blijft houden in zaken als dit ga ik niet aanpassen want dat werkt nu goed kom je ook niet verder. Je bent al 3x van platform veranderd, maar waarom? iets zegt me dat dit systeem ook prima gemaakt had kunnen worden op een atmega 2560 of een stm32. Zolang je je code niet fatsoenlijk opzet, gaat het op geen 1 architectuur fatsoenlijk werken
Je zegt dat je nu je pulsen maakt met een for loop inclusief de homing en versnelling etc.
Op zich helemaal prima, maar als dat in je main loop gebeurt dan zal je hele timing altijd afhankelijk worden van de rest van de taken in je software.
Daarom kun je zeer waarschijnlijk deaelfde functie met wat minimale aanpassingen in een interrupt uitvoeren.
Het gebruik van een aparte controller voor de motor sturing lijkt me persoonlijk echt niet nodig of iets toevoegen aan dit probleem.
Die controller moet dan ook nog steeds een communicatie protocolletje hebben met de main controller, dus veranderd er vrij weinig.
Als je nu ene zeer hoog frequentie commutatie motor sturing hebt wordt het een wat ander verhaal, maar dit is toch allemaal niet zo spannend.
Het ontbreekt hier echter gewoon aan een degelijk design en een overzicht van taken
MGP
LDmicro user.
Op vrijdag 21 juni 2024 07:45:34 schreef Stijnos:
...
Het gebruik van een aparte controller voor de motor sturing lijkt me persoonlijk echt niet nodig of iets toevoegen aan dit probleem.
Die controller moet dan ook nog steeds een communicatie protocolletje hebben met de main controller, dus veranderd er vrij weinig.
Dat zit ik nu al gans de tijd uit te leggen dat dit niet nodig zou zijn, een poortje hoog/laag maken na 100pulsen en de communicatieprocessor kan zijn werk beginnen zonder zich zorgen te maken over de motor.
Voor de rest geef ik je wel gelijk, maar ik geef hem ook deels gelijk, als je al veel werk hebt gestoken in een project en alles moet omgooien dan zou ik ook 2x nadenken.
Ik vermoed dat het nog altijd om dit project gaat.
klopt, maar refactoring hoort er nu eenmaal bij. Als je basis r%@#k is en daarmee bijvoorbeeld je timing geheel afhankelijk is van je gehele main loop die vol delays zit, dan is elke uitbreiding aan je systeem vragen om problemen. Ik zou de TS graag helpen met een solide opzet die niet geheel bestaat aan in elkaar verweven taken en ik bewonder zijn jaren lange doorzetting om dit mysterieuze apparaat te ontwikkelen beginnend met 0 kennis, maar als je de fundamentele dingen niet fatsoenlijk oplost dan blijft het een totaal niet onderhoud baar project
ik reageer straks wat inhoudelijker, ik ben nu het dual-core gebeuren aan het testen.
dit project, wat inderdaad al een paar jaar loopt is een redelijk groot hobby project, wat heel goed op te splitsen is in een aantal kleine delen.
die delen komen ook sequentieel na elkaar, niets gaat tegelijk op 1 uitzondering na: het geen waar ik nu mee bezig ben, een beweging die om de 100 pulsen een bericht over de UART verstuurd (zonder die beweging te beïnvloeden). ik werk ook niet continu aan dit project, doe er soms maanden (of langer) niets aan.
en dit is inderdaad mijn 3e controller:
1 - atmega 2560, begonnen met het programma verkeerd op bouwen, waardoor het een "brei" werd, en een verkeerde HMI gekozen. bovendien vond ik de controller wat gedateerd.
dat verkeerd opbouwen v/h programma, is waar jullie veelvuldig voor waarschuwen, en terecht, dat doe ik nu veel beter, al zal het in de ogen van een "echte" programeur nog niet goed zijn natuurlijk
2 - STM32 volgens mij niks mis met de controller, maar ik gebruikte cube-IDE
niks voor mij, veel te veel toeters en bellen die voor een eenvoudige hobby programmeur alleen verwarrend werken. ik kon er niet aan wennen, de lay-out waar je in programmeert is heel druk, en dan kan je alleen in bepaalde stukken je eigen programma zetten. een drama.
3 - raspberry pico,......kijk dat is iets voor mij zit al op een break out bord, voorziening om met de USB kabel te programmeren, modern, programeer micro python m.b.v de thonny IDE (ontwikkeld voor de beginner, en laat ik dat nou toevallig zijn 
) wat een rustige lay-out heeft zonder veel toeters en bellen, voldoende over te vinden, zal wel de benodigde beperkingen hebben, maar ik denk niet dat ik die veel tegen ga komen.
het enigste tot nu toe is dat ik eigenlijk een UART te kort kom.
en wat ook een enorme stap voorwaarts was, is het gebruik van een nextion HMI, dat scheelde een berg code in mijn programma.
als ik dus een vraag heb is dat altijd een klein deeltje van het totaal, als ik daarbij het totaal moet uitleggen dan "verzand" de eigenlijke vraag in van alles,..... kan je het beter niet zus of zo doen ? kijk eens naar dit voorbeeld die doen het anders (beter). hoe ga je zo meteen dit doen of, dat doen. allemaal goed bedoeld en het word enorm door mij gewaardeerd 
, maar je drijft heel snel af van waar het om ging (de eigenlijke vraag).
o ja,...ik heb het al eens gezegd, iedereen waar ik hulp van krijg mag komen kijken (nuland bij den bosch)
benleentje
Golden Member
en wat ook een enorme stap voorwaarts was, is het gebruik van een nextion HMI, dat scheelde een berg code in mijn programma.
In jouw programma wel maar je moet dan ook naar de totale omvang van het programma kijken wat er dan in de microcontroller word geprogrammeerd. En dan zie je vaak dat het om een hele berg code gaat.
jawel...ik heb weer een python vraag .
ik wil 230 bytes die ik over de UART binnen krijg opslaan, zodat ik die later kan bewerken.
ik krijg ze gewoon keurig binnen, alleen het opslaan wil nog niet lukken.
nu zit ik al een paar dagen te kijken en te zoeken hoe ik dat het beste kan doen, met een array met een bytearray of met een list.
ik zie het gewoon niet.
ik heb de code vereenvoudigd om het te kunnen testen, i.p.v. 230 byte doe ik het met 20 bytes. die krijg ik keurig binnen zoals op de printscreen is te zien (i.p.v. 106 stuur ik een 0).
maar hoe sla ik die 20 bytes (later 230) het best op ? en het liefst in een hex notatie en niet in ascii.
Tnx.
from machine import Pin, Timer, I2C, UART
import time
scanner_read_write = Pin(28, Pin.OUT) # scanner read write
scanner_read_write.value(0) #read write
uart = UART(0, baudrate=9600, tx=Pin(0), rx=Pin(1)) # touch screen
scanner_uart = UART (1, baudrate=9600, tx=Pin(4), rx=Pin(5)) # scanner
while True:
if uart.any(): # see or anything is comming from the touchscreen
data = uart.read()
print (data) # tester
if data== b'$0103P&': # TEST 1 button
print ("tester 1")
scanner_read_write.value(1) # 1 = write and 0 = read MAX485
time.sleep_ms (3)
command = b'\x17' # adress byte hex 17 = dec 23
scanner_uart.write(command)
time.sleep_ms (3)
command = b'\x02 ' # send your 1e byte to me
scanner_uart.write(command)
time.sleep_ms (3)
command = b'\xFF' # stop byte
scanner_uart.write(command)
time.sleep_ms (3)
scanner_read_write.value(0) # 1 = write and 0 = read MAX485
if scanner_uart.any(): # see or anything is comming from the scanner
datas = scanner_uart.read(20)
print([byte for byte in datas])
KGE
Golden Member
Is het nu Bascom of Python ?
Ik neem aan dat Bascom (net als Python) wel zoiets kent als een 'array' ? Daarin kun je genummerd waardes opslaan.
https://avrhelp.mcselec.com/index.html?dim.htm
https://www.w3schools.com/python/python_arrays.asp
[Bericht gewijzigd door KGE op (26%)]
Je kunt datas gewoon bewaren. Nu stop je daar 20 bytes in, en het maakt python geen ruk uit als je er 230 instopt.
De UART.read functie geeft je een python bytes object terug. Dat is een serie van 0 of meer losse bytes. Precies wat je wil bewaren
Als je het later dan als hex wil printen:
for bijt in datas :
print("0x%02x ", bijt)
Of als je de som wilt nemen:
som=0
for bijt in datas :
som = som+bijt
Grote mega's bijten niet.
Op donderdag 20 juni 2024 17:39:42 schreef fatbeard:
Ik net ook weer...
daar schijnt de naam python ook vandaan te komen, de bedenker was een fan van montypython.
Op donderdag 5 september 2024 21:03:25 schreef blurp:
Je kunt datas gewoon bewaren. Nu stop je daar 20 bytes in, en het maakt python geen ruk uit als je er 230 instopt.De UART.read functie geeft je een python bytes object terug. Dat is een serie van 0 of meer losse bytes. Precies wat je wil bewaren
maar de vraag is eigenlijk, hoe sla ik die het best op, b.v. in een array, bytearray of in een list, of iets anders ?
MGP
LDmicro user.
Op donderdag 5 september 2024 23:57:58 schreef Henry S.:
[...]
Ik net ook weer...
Kan de topictitel dan niet veranderd worden naar een meer inhoudelijke beschrijving? bv. 'De ontwikkeling van een levensgrote scanner' of wat de TS verkiest?