/ Forside / Teknologi / Udvikling / VB/Basic / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
VB/Basic
#NavnPoint
berpox 2425
pete 1435
CADmageren 1251
gibson 1230
Phylock 887
gandalf 836
AntonV 790
strarup 750
Benjamin... 700
10  tom.kise 610
Hjælp Kinasyndrom under udvikling
Fra : Bjarne Østergård


Dato : 31-03-01 14:41

Hej jeg håber der er nogle kvikke fyre eller fyrinder der er gode til lidt
logiksk tænkning og som kan hjælpe mig lidt, ellers er jeg bange for at min
hjerne laver en nedsmeltning der får Kinasyndromet til at ligne en udbrændt
stjernekaster.

Det startede med at jeg gav tilbud på at udvikle et stykke simpelt software
til styrring af et lille sorteringsanlæg.

Anlæget har 10 stationer og der skal kunne lægges en bestemt vægt på hver
station hvorefter den tømmes og den fyldes så op påny til den ønskede vægt
igen er nået.

Mit indput kommer fra et bånd med stykker der måles og vejes, stykkerne kan
have forskellig vægt fra 5 til 150 Gr.

Jeg skal nu fordele dem således på de 10 stationer at der altid er et større
stykke oven på et mindre, og således at vægten på stationen holdes inden for
en givet tolerance. plus minus så lidt som muligt, men en ca 10 Gr til hver
side er nok rimeligt.

F.eks hvis man siger at der skal pakkes i bakker af 300 gr. kan jeg
aflevere 30 stk af 10 gr. eller jeg kan aflevere to på 50 Gr. et på 100 Gr.
og et på 200 Gr.

Men ikke i omvendt rækkefølge da det største stykke altid skal lægge øverst.

Det er dog tilladt at lægge to af samme størrelse oven på hinnanden.

Og stationen skal vælges når stykket vejes. man kan altså ikke køre tilbage
med stykket igen, eller fortryde.

Når båndet kommer til enden af de ti stationer skal det være tømt, og
stykkerne afleveret på en af stationerne da maskinen ikke kan bakke eller
vente med at aflevere stykket.

Når en station er fyldt op til den ønskede vægt tømmes den og der startes
forfra med at fylde den op.

Jeg har lavet forskellige opstillinger med array der gennemløber systemet
men jeg kan sgu ikke få det til at lykkedes.

De 9 stationer skal gå til pakning og forsendelse, den sidste Nr. 10 er til
de stykker der kasseres altså er under F.eks 5 Gr. eller over 150 Gr.

Håber altså nogen har nogle ideer, da jeg er træt af at sidde med hovedet i
fryseren og med isterninger proppet ind i ørene.


--
Med venlig hilsen
Bjarne Østergård
Gigasoft Danmark
www.gigasoft.dk
boe@gigasoft.dk
Tlf: 86 49 64 04





 
 
Tomas Christiansen (31-03-2001)
Kommentar
Fra : Tomas Christiansen


Dato : 31-03-01 21:41

Bjarne Østergård skrev:
> Jeg skal nu fordele dem således på de 10 stationer at der altid er et
større
> stykke oven på et mindre, og således at vægten på stationen holdes inden
for
> en givet tolerance. plus minus så lidt som muligt, men en ca 10 Gr til
hver
> side er nok rimeligt.
>
> F.eks hvis man siger at der skal pakkes i bakker af 300 gr. kan jeg
> aflevere 30 stk af 10 gr. eller jeg kan aflevere to på 50 Gr. et på 100
Gr.
> og et på 200 Gr.

Hvordan giver 2x50 + 100 + 200 = 400 en tolerance op ca. 10 gram til hver
side, når 300 gram er det ønskede resultat?
Er der noget jeg har misset?

> Og stationen skal vælges når stykket vejes. man kan altså ikke køre
tilbage
> med stykket igen, eller fortryde.

Vil det sige, at du er nødt til at acceptere et stykke inden du ved hvad det
vejer?
....og at du dermed altid vil kunne risikere at kunne få en overvægt på
vægten af det størst mulige stykke minus én eller anden grænseværdi, som du
sætter for hvornår en station er "fyldt op".

-------
Tomas



Tomas Christiansen (31-03-2001)
Kommentar
Fra : Tomas Christiansen


Dato : 31-03-01 23:37

Tomas Christiansen skrev:
> Vil det sige, at du er nødt til at acceptere et stykke inden du ved hvad
det
> vejer?
> ...og at du dermed altid vil kunne risikere at kunne få en overvægt på
> vægten af det størst mulige stykke minus én eller anden grænseværdi, som
du
> sætter for hvornår en station er "fyldt op".

Glem det! Da jeg læste dit indlæg igen forstod det.

Jeg har et par tillægsspørgsmål:

Skal den tid det tager at tømme en station tages i betragtning?

Eller kan man altid regne med at når en station er fyld op til den ønskede
grænse, er den "øjeblikkelig" herefter klar til at modtage igen (når stykket
engang kommer ud til den)?

Kan man vide noget om stykkernes vægtfordeling (mange små, få store, osv.)?

Du kan vel ikke være sikker på at undgå en situation, hvor der på bakkerne
1-9 ligger et stykke på 100 gram, og at det næste stykke er på 90 gram? Dvs.
at du må kassere stykket, selv om det overholder vægtspecifikationerne!

-------
Tomas



Bjarne Østergård (01-04-2001)
Kommentar
Fra : Bjarne Østergård


Dato : 01-04-01 09:03


"Tomas Christiansen" <toc@blikroer.removethis.dk> wrote in message
news:W_sx6.295$a6.10448@news.get2net.dk...
>
> Jeg har et par tillægsspørgsmål:
>
> Skal den tid det tager at tømme en station tages i betragtning?

Nej det regner jeg ikke med. men på tirsdag skal jeg til Hirtshalds og se en
maskine i funktion hvor der sorteres manuelt og så vil jeg have nogle flere
data om hvad der er muligt, og en del mere om kravene.


> Eller kan man altid regne med at når en station er fyld op til den ønskede
> grænse, er den "øjeblikkelig" herefter klar til at modtage igen (når
stykket
> engang kommer ud til den)?
ja ellers må båndet vente på at den nye station med bakke når på plads, det
hele styres med nogle stepmotore som er rimeligt nemme at programmere via et
IO kort.

> Kan man vide noget om stykkernes vægtfordeling (mange små, få store,
osv.)?
Ja men kun til dels, der bliver op til ca 30 til 50 skiver laks af en fisk
og de største skiver kommer på midten.
Dog kan der også til dels kompenseres for dette ved at vippe fisken under
skærringen så stykkerne bliver så tæt på hinnanden som muligt.
men ens kan man ikke få dem.
Selve snittet af fisken sker i en slaks pålægsmaskine.
Du kender nok de bakker med tynde lakseskiver fra butikkerne, og det er
denne pakkeproces jeg skal forsøge at løse med et stykke software.


> Du kan vel ikke være sikker på at undgå en situation, hvor der på bakkerne
> 1-9 ligger et stykke på 100 gram, og at det næste stykke er på 90 gram?
Dvs.
> at du må kassere stykket, selv om det overholder vægtspecifikationerne!

Nej det har min program også vist men jeg skal på en eller anden måde have
minimeret dette spild
og det er derfor jeg håbede på at en eller anden havde en ide til hvordan.

Jeg vil forsøge at få lov til lave det således, at der blot kommer et stort
stykke i toppen og at alle underliggende lag så er ligegyldigt, da kravet
til de større og større stykker skyldets at de præsenterer sig bedere i
forretningen når de største stykker er øverst.

Nå men på tirsdag ved jeg lidt mere da jeg da skal op på en fabrik og se en
maskine med manuel sortering i drift, og jeg regner med at kunne indsamle
lidt flere data om processen.


--
Med venlig hilsen
Bjarne Østergård
Gigasoft Danmark
www.gigasoft.dk
boe@gigasoft.dk
Tlf: 86 49 64 04









Tomas Christiansen (01-04-2001)
Kommentar
Fra : Tomas Christiansen


Dato : 01-04-01 22:02

Bjarne Østergård skrev:
> ja ellers må båndet vente på at den nye station med bakke når på plads,
det
> hele styres med nogle stepmotore som er rimeligt nemme at programmere via
et
> IO kort.

Vil det sige at du kan stoppe hele båndet? Hvad så med de skiver, som er på
vej til vægten?

Det lyder ikke som nogen særlig rar situation!

Jeg har en gang arbejdet på en spraydåse-fabrik, og har set hvad der sker,
når blot en enkelt spraydåse med gummifornyer (noget MEGET klistret sort
stads) vælter på båndet, og alle de andre spraydåser kommer og presser på.
Man har kun ganske få sekunder til at smide sig på gulvet før det siger BANG
.... SPLAT.

Med hvilket tidsinterval lægges skiverne egentlig på båndet? De kommer vel
formentlig temmelig tjept?

> Ja men kun til dels, der bliver op til ca 30 til 50 skiver laks af en fisk
> og de største skiver kommer på midten.

Denne information kan nok ikke bruges til så voldsomt meget, andet end at to
på hinanden følgende skivers vægt er typisk ret ens. Men det er dog bedre
end ingenting.

> Du kender nok de bakker med tynde lakseskiver fra butikkerne, og det er
> denne pakkeproces jeg skal forsøge at løse med et stykke software.

Alt godt fra havet - nu programmeret i VB.

> Nej det har min program også vist men jeg skal på en eller anden måde have
> minimeret dette spild og det er derfor jeg håbede på at en eller anden
havde
> en ide til hvordan.

Hvad er værst: At nogle af bakkerne har en stort overvægt eller at de gode,
store, pæne stykker ryger til station 10?

Det vil måske vise sig at 9 stationer er for lidt til en tolerance på 10
gram. Især set i lyset af (min formodning om) at vægten på skiverne kun
stiger eller falder lidt, for hver gang der kommer en ny skive.

Hvis skiverne kom i helt tilfældig vægt-orden, ville der måske være en
større chance for at kunne fordele dem godt i bakkerne!

Et tankeeksperiment:
1. Alle stationer er næsten fyldt op - de mangler alle kun en lille skive.
2. En meget stor fisk bliver skåret op. Alle stykkerne (i starten bliver de
større og større - derefter bliver de mindre og mindre) er for store til at
nogen af stationerne vil modtage dem, idet der kommer alt for meget
overvægt. Den sidste skive er fra havestykket og er lille nok til at station
1 får den - de øvrige kasseres. Station 1 er nu fyldt op, tømmes og er klar
til at modtage igen.
3. En meget stor fisk bliver skåret op. Alle stykkerne (i starten bliver de
større og større - derefter bliver de mindre og mindre) er for store til at
nogen af stationerne 2-9 vil modtage dem, idet der kommer alt for meget
overvægt. De første skiver lander i station 1 indtil den er fyldt op. Den
sidste skive er fra havestykket og er lille nok til at station 1 får den -
de øvrige kasseres. Station 1 er nu fyldt op, tømmes og er klar til at
modtage igen.
4. Gå til punkt 3.

En lidt kedelig situation: Der KOMMER skiver til én af stationerne, men det
meste fisk kasseres. Jeg tror at du skal tænke dig grundigt om (kør en masse
simuleringer), for at undgå sådanne situationer. Evt. skal en dialog-boks
poppe op og bede om at få en LILLE fisk serveret for at løse op for
situationen

> ...da kravet til de større og større stykker skyldets at de præsenterer
> sig bedere i forretningen når de største stykker er øverst.

Igen er spøgsmålet hvad er værst: At nogle stykker kasseres, eller at der en
gang imellem "ses gennem fingre" med kravet om større og større stykker.

En sidste ting: Hvordan ved en stykke fisk hvornår det er ud for den rigtige
station, og hvordan får man det til at hoppe op i bakken? Tæller man steps
på motoren som driver båndet, og så ved man hvor fisken burde befinde sig
eller kan stationerne "se"?
-------
Tomas



Bjarne Østergård (02-04-2001)
Kommentar
Fra : Bjarne Østergård


Dato : 02-04-01 08:25


"Tomas Christiansen" <toc@blikroer.removethis.dk> wrote in message
news:wHMx6.620$p11.15018@news.get2net.dk...
> Bjarne Østergård skrev:
> > ja ellers må båndet vente på at den nye station med bakke når på plads,
> det
> > hele styres med nogle stepmotore som er rimeligt nemme at programmere
via
> et
> > IO kort.
>
> Vil det sige at du kan stoppe hele båndet? Hvad så med de skiver, som er

> vej til vægten?
Skiverne vil jeg ikke veje men fotograffere og herudfra beregne vægt og
størrelse
Og båndet vil stoppe i ca 0,5 sek hver gang en ny skive opskæres.
Så det vil betyde ca 2 skiver pr. sek.

> Det lyder ikke som nogen særlig rar situation!
>
> Jeg har en gang arbejdet på en spraydåse-fabrik, og har set hvad der sker,
> når blot en enkelt spraydåse med gummifornyer (noget MEGET klistret sort
> stads) vælter på båndet, og alle de andre spraydåser kommer og presser på.
> Man har kun ganske få sekunder til at smide sig på gulvet før det siger
BANG
> ... SPLAT.
Så aggressiv er et stykke laks ikke og skiverne hænger på et bånd lige som
tøj på en tøjsnor.

> Med hvilket tidsinterval lægges skiverne egentlig på båndet? De kommer vel
> formentlig temmelig tjept?
0,5 sek.

> > Ja men kun til dels, der bliver op til ca 30 til 50 skiver laks af en
fisk
> > og de største skiver kommer på midten.
>
> Denne information kan nok ikke bruges til så voldsomt meget, andet end at
to
> på hinanden følgende skivers vægt er typisk ret ens. Men det er dog bedre
> end ingenting.
>
> > Du kender nok de bakker med tynde lakseskiver fra butikkerne, og det er
> > denne pakkeproces jeg skal forsøge at løse med et stykke software.
>
> Alt godt fra havet - nu programmeret i VB.
Ja og jeg regner da med at systemet når først jeg har fået det udviklet skal
kunne bruges til mange andre maskiner også

> > Nej det har min program også vist men jeg skal på en eller anden måde
have
> > minimeret dette spild og det er derfor jeg håbede på at en eller anden
> havde
> > en ide til hvordan.
>
> Hvad er værst: At nogle af bakkerne har en stort overvægt eller at de
gode,
> store, pæne stykker ryger til station 10?
Ja det vil jeg tale med min kunde om. for mine testkørsler viser at der skal
foretages et valg.

> Det vil måske vise sig at 9 stationer er for lidt til en tolerance på 10
> gram. Især set i lyset af (min formodning om) at vægten på skiverne kun
> stiger eller falder lidt, for hver gang der kommer en ny skive.
>
> Hvis skiverne kom i helt tilfældig vægt-orden, ville der måske være en
> større chance for at kunne fordele dem godt i bakkerne!
>
> Et tankeeksperiment:
> 1. Alle stationer er næsten fyldt op - de mangler alle kun en lille skive.
> 2. En meget stor fisk bliver skåret op. Alle stykkerne (i starten bliver
de
> større og større - derefter bliver de mindre og mindre) er for store til
at
> nogen af stationerne vil modtage dem, idet der kommer alt for meget
> overvægt. Den sidste skive er fra havestykket og er lille nok til at
station
> 1 får den - de øvrige kasseres. Station 1 er nu fyldt op, tømmes og er
klar
> til at modtage igen.
> 3. En meget stor fisk bliver skåret op. Alle stykkerne (i starten bliver
de
> større og større - derefter bliver de mindre og mindre) er for store til
at
> nogen af stationerne 2-9 vil modtage dem, idet der kommer alt for meget
> overvægt. De første skiver lander i station 1 indtil den er fyldt op. Den
> sidste skive er fra havestykket og er lille nok til at station 1 får den -
> de øvrige kasseres. Station 1 er nu fyldt op, tømmes og er klar til at
> modtage igen.
> 4. Gå til punkt 3.
Ja det var nettop dette problem der fik mig til at skrive her i gruppen.

> En lidt kedelig situation: Der KOMMER skiver til én af stationerne, men
det
> meste fisk kasseres. Jeg tror at du skal tænke dig grundigt om (kør en
masse
> simuleringer), for at undgå sådanne situationer. Evt. skal en dialog-boks
> poppe op og bede om at få en LILLE fisk serveret for at løse op for
> situationen



> > ...da kravet til de større og større stykker skyldets at de præsenterer
> > sig bedere i forretningen når de største stykker er øverst.
>
> Igen er spøgsmålet hvad er værst: At nogle stykker kasseres, eller at der
en
> gang imellem "ses gennem fingre" med kravet om større og større stykker.
>
> En sidste ting: Hvordan ved en stykke fisk hvornår det er ud for den
rigtige
> station, og hvordan får man det til at hoppe op i bakken? Tæller man steps
> på motoren som driver båndet, og så ved man hvor fisken burde befinde sig
> eller kan stationerne "se"?

Man tæller step og en magnetventil aktiveres ud for stationen når stykket er
nået frem, og stykket bliver flyttet fra fødebånd til bakken.


--
Med venlig hilsen
Bjarne Østergård
Gigasoft Danmark
www.gigasoft.dk
boe@gigasoft.dk
Tlf: 86 49 64 04






Niels (02-04-2001)
Kommentar
Fra : Niels


Dato : 02-04-01 23:48


"Bjarne Østergård" <boe@gigasoft.dk> skrev i en meddelelse
news:9a99gq$8va$1@news.cybercity.dk...

en masse problemer

Er maskinen helt færdig og klar til at køre ?

Ellers ville jeg da foreslå indføre en form for vendefunktion, så man reelt
skulle starte med de store og slutte med de små, og så derefter vende det.

Jeg er godt klar over at det ikke løser hele problemet, men det hjælper da.

--
Med venlig hilsen
Niels E. Jensen

Niels.Jensen@Cool.dk






Bjarne Østergård (01-04-2001)
Kommentar
Fra : Bjarne Østergård


Dato : 01-04-01 08:48


"Tomas Christiansen" <toc@blikroer.removethis.dk> wrote in message
news:Jhrx6.255$a6.7259@news.get2net.dk...
> > F.eks hvis man siger at der skal pakkes i bakker af 300 gr. kan jeg
> > aflevere 30 stk af 10 gr. eller jeg kan aflevere to på 50 Gr. et på 100
> Gr.
> > og et på 200 Gr.
>
> Hvordan giver 2x50 + 100 + 200 = 400 en tolerance op ca. 10 gram til hver
> side, når 300 gram er det ønskede resultat?
> Er der noget jeg har misset?
Beklager det var en dum fejl fra min side.


> > Og stationen skal vælges når stykket vejes. man kan altså ikke køre
> tilbage
> > med stykket igen, eller fortryde.
>
> Vil det sige, at du er nødt til at acceptere et stykke inden du ved hvad
det
> vejer?
nej men lige så snart jeg kender vægten skal jeg også vælge den station det
skal lægges på. og jeg kan f.eks ikke fortryde hvis det stykke der kommer
efter ville have givet et andet valg der ville have været bedre.

> ...og at du dermed altid vil kunne risikere at kunne få en overvægt på
> vægten af det størst mulige stykke minus én eller anden grænseværdi, som
du
> sætter for hvornår en station er "fyldt op".

Ja faktisk hvis jeg F.eks mangler 20 gr. må stationen vente på at der
kommer et stykke på mindst 10 eller max 30 Gr. før den kan tømmes, hvis jeg
skal holde tolerencen på 10



--
Med venlig hilsen
Bjarne Østergård
Gigasoft Danmark
www.gigasoft.dk
boe@gigasoft.dk
Tlf: 86 49 64 04




N/A (01-04-2001)
Kommentar
Fra : N/A


Dato : 01-04-01 08:44



Bjarne Østergård (01-04-2001)
Kommentar
Fra : Bjarne Østergård


Dato : 01-04-01 08:44


"Mila" <Mila@image.dk> wrote in message
news:hpox6.7845$o4.292160@news010.worldonline.dk...
> Hej Bjarne
>
> Det lyder til at være en spændende opgave. Hvad sker der, når de første ni
> bakker er fyldt med ca. 250-280 gram indhold og det næste stykke på båndet
> vejer 100 gram?
Når bakkerne har nået den ønskede vægt køres de væk og stationen begynder
forfra

Det er nettop det der er problemet, jeg har lavet et program der kører med
nogle tilfældige valgte værdier mellem 5 og 150
I starten kan det lade sig gøre at placere alle stykker men ikke uden mindst
100 i tolerence, efter et stykke tid bliver det af en eller anden grund
umuligt og næsten hver anden stykke kan ikke længere placeres hvis reglerne
skal overholdes.

I dag bliver det manuelt sorteret og pakket.


--
Med venlig hilsen
Bjarne Østergård
Gigasoft Danmark
www.gigasoft.dk
boe@gigasoft.dk
Tlf: 86 49 64 04




Morten Fast (02-04-2001)
Kommentar
Fra : Morten Fast


Dato : 02-04-01 21:41

"Bjarne Østergård" <boe@gigasoft.dk> wrote in message
news:9a4mqg$2ggs$1@news.cybercity.dk...
> Håber altså nogen har nogle ideer, da jeg er træt af at sidde med
> hovedet i fryseren og med isterninger proppet ind i ørene.

Hej Bjarne

Jeg sad lige og grublede lidt over det, og jeg tror,
jeg ville lave to klasser: En bakke-klasse og en
bakkemaster-klasse

Bakken ved, hvor meget den vejer, og hvor stort det øverste
stykke er. Intet andet. Den har så en enkelt funktion,
der kan tilføje en fisk til bakken.

Bakke-masteren har et array/collection af bakke-klasser,
men den opretter kun nye bakker, hvis det er nødvendigt,
og sletter bakkerne igen, når de er kørt af båndet.
Optimalt set, kan man jo nøjes med en enkelt bakke.
(det sker sandsynligvis aldrig, men optimalt set...)


Bakke-klasse:
--------------
TotalVægt
StørrelsePåØversteStykke
TilføjFisk(ByVal Fisk As Long)

Bakke-master-klasse:
--------------------
AlleBakker
IdealvægtPåBakke
Margin
MaxAntalBakker
MindsteTilladteStykke
StørsteTilladteStykke
TagNyBakkeIBrug()
TømBakke(ByRef aBakke As Bakke)
PlacerFisk(ByVal Fisk As Long)



Så har man et almindeligt modul:


Do While Der Stadig Kommer Fisk

PlacerFisk(DenNæsteFisk)

Loop



Det svære kommer så i PlacerFisk-subben i
Bakke-master-klassen.

Lidt pseudokode:


Private Sub PlacerFisk(ByVal Fisk As Long)

If Fisk uden for den tilladte størrelse
Smid den i skraldebakken
Exit Sub
End If

For Each Bakke In AlleBakker

If Fisk >= Bakke.StørrelsePåØversteStykke AND _
Bakke.totalvægt + fisk <= idealvægt +/- Margin

If bakke.totalvægt + fisk stadig tillader at en fisk
af mindst samme størrelse bliver tilføjet...

Læg den i den aktuelle bakke
Exit Sub

Else

If Bakke.Totalvægt + Fisk = idealvægt +/- margin

Læg den i den aktuelle bakke
Tøm den aktuelle bakke
Exit Sub

End If

End If

End If

Next

' Alle nuværende bakker er tjekket, og den er stadig ikke
' placeret endnu. Vi må tage en ny bakke i brug, hvis der
' er flere...
If AlleBakker.Count < MaxAntalBakker

TagNyBakkeIBrug()
Tilføj fisken til den nye bakke.

Else

' der er ikke flere tomme bakker at give af, så fisken
' skal enten kasseres, eller lægges i en bakke, der ikke
' rammer idealvægten helt.
Find bakken hvor totalvægt + fisk er tættest på idealvægten
Tilføj fisken til bakken
Tøm bakken

End if

End Sub


Du kan så inden du tager en ny bakke i brug - for at undgå
at blive fanget med 9 bakker med store stykker i - tjekke,
om stykket er max f.eks. en trediedel af idealvægten.

Hvis det er større, må det ikke være det første stykke, for
så har du en halvlåst bakke, der kun kan tage rigtig store
stykker.

Så hellere smide stykket i en bakke, der så ikke rammer
idealvægten 100%.


Jeg håber, du kan bruge det til noget.

Vh Morten




Tomas Christiansen (02-04-2001)
Kommentar
Fra : Tomas Christiansen


Dato : 02-04-01 22:48

Morten Fast skrev:
> Jeg sad lige og grublede lidt over det, og jeg tror,
> jeg ville lave to klasser: En bakke-klasse og en
> bakkemaster-klasse

> Bakken ved, hvor meget den vejer, og hvor stort det øverste
> stykke er. Intet andet. Den har så en enkelt funktion,
> der kan tilføje en fisk til bakken.


Hvem holder så styr på de stykker, som er på vej ud til en station med en
ikke-fuld bakke?
....og når man ved, at bakken bliver fyldt op og derefter udskiftet med en
ny, når med de stykker, som er sendt afsted, kommer frem, kan man jo
allerede begynde at sende nye stykker afsted til den ny tomme bakke (som jo
altså endnu ikke er sat i stationen).

Man kunne vel også tænke sig at der kommer små bakker, store bakker, bakker
med kun store stykker, bakker med skrammel, begræsning af antallet af
stykker i en bakke osv.

Jeg tror at en station kommer til at skulle vide mere om sig selv og sin
bakke end blot vægt+største stykke, og jeg tror at objekt-modellen skal være
noget større for at kunne håndtere alt hardwaren og alle situationerne
korrekt, men jeg er helt enig i at det ligner en OPLAGT objektorienteret
opgave!

Umiddelbart ville jeg nok tænke i retning af følgende klasser:

Konfiguration: Indeholder en beskrivelse af hardware konfigurationen med
mulighed for at ændre og læse fra/gemme på disk.
Vægt: Finder ud af hvad stykket vejer, får at vide hvilken station det skal
sendes til og placerer det på båndet.
Bånd: Simulerer båndets bevægelse.
Station: Tager stykket af båndet, og lægger det i bakken. Ved hvor mange
stykker der er i bakken, deres vægt og hvilke stykker der er på vej (og
deres vægt).
Fordeler: Kan tage beslutninger om hvordan stykkerne skal fordeles.
Kontaktes af vægten.
Konsol: Kommunikation med skærmen. Viser systemets status, visse statistiske
data og giver mulighed for at ændre på visse parametre (f.eks. tage en
station ud af midlertidigt ud af drift).
Historik: Gemmer en historik over fordelingen af stykkerne. Kan bruges til
at køre gennem en simulator for at se effekten af diverse forsøg på
forbedringer, og mindsker nødvendigheden af fysiske tests ganske
betragteligt.
Statistik: Kan foretage visse statitiske udregninger for brugeren.
Diverse objekter til at simulere step-moterer m.m.

> Bakke-masteren har et array/collection af bakke-klasser,
> men den opretter kun nye bakker, hvis det er nødvendigt,
> og sletter bakkerne igen, når de er kørt af båndet.

Det er vel kun nødvendigt at oprette et objekt pr. station én gang.
Stationerne bliver formentlig ved med at være der hele tiden (med mindre de
går i stykker, hvorefter de naturligvis skal kunne "tages ud" af systemet).

> Optimalt set, kan man jo nøjes med en enkelt bakke.
> (det sker sandsynligvis aldrig, men optimalt set...)

Enig.

> Du kan så inden du tager en ny bakke i brug - for at undgå
> at blive fanget med 9 bakker med store stykker i - tjekke,
> om stykket er max f.eks. en trediedel af idealvægten.
>
> Hvis det er større, må det ikke være det første stykke, for
> så har du en halvlåst bakke, der kun kan tage rigtig store
> stykker.
>
> Så hellere smide stykket i en bakke, der så ikke rammer
> idealvægten 100%.

Det lyder ret fornuftigt.

-------
Tomas



Morten Fast (03-04-2001)
Kommentar
Fra : Morten Fast


Dato : 03-04-01 18:14


"Tomas Christiansen" <toc@blikroer.removethis.dk> wrote in message
news:Is6y6.571$HY1.24034@news.get2net.dk...

> Hvem holder så styr på de stykker, som er på vej ud til en station
> med en ikke-fuld bakke?

Det skal bakkemaster-klassen gøre. Den ved, hvilke bakker der er i brug,
og hvilke bakker den kan sende hvilke stykker afsted til.
Den sørger også for, at stykkerne har fået udpeget en bakke, inden
de kommer ud på båndet.


> ...og når man ved, at bakken bliver fyldt op og derefter udskiftet med
> en ny, når med de stykker, som er sendt afsted, kommer frem, kan man
> jo allerede begynde at sende nye stykker afsted til den ny tomme bakke
> (som jo altså endnu ikke er sat i stationen).

Det er principielt set ligegyldigt.
Det kan reelt give et problem, men man kan f.eks. nedskrive antallet
af tilladte bakker med 1, indtil den nye bakke er på plads.
Men for princippet er det underordnet.


> Man kunne vel også tænke sig at der kommer små bakker, store bakker,
> bakker med kun store stykker, bakker med skrammel, begræsning af
> antallet af stykker i en bakke osv.

Det er udelukkende et spørgsmål om at justere egenskaberne
for bakkemaster-klassen.


> Jeg tror at en station kommer til at skulle vide mere om sig selv
> og sin bakke end blot vægt+største stykke

Hvorfor? Og hvad?


> og jeg tror at objekt-modellen skal være noget større for at kunne
> håndtere alt hardwaren og alle situationerne korrekt

Helt sikkert. De to klasser er udelukkende til sortering af stykker.
Det samlede system vil være væsentlig større.


> Umiddelbart ville jeg nok tænke i retning af følgende klasser:
[Snip - en masse klasser]

Jeg vil nok mene, at mange af de klasser du nævner,
blot er funktioner på en større klasse.

> Det er vel kun nødvendigt at oprette et objekt pr. station én gang.
> Stationerne bliver formentlig ved med at være der hele tiden (med mindre
de
> går i stykker, hvorefter de naturligvis skal kunne "tages ud" af
systemet).

Nej, ikke hvis man skal følge en objektorienteret analogi
til virkeligheden.
Antallet af stationer defineres i bakkemasterklassen, som det
maksimalt tilladte antal bakker.
Man behøver ikke at tage ti bakker i brug, bare fordi man kan.
Hvis een bakke er nok, så er flere bakker bare spild.

Hvorfor tage objekter i brug, som du sandsynligvis ikke får brug for?

Det er en balancegang mellem hurtig søgning efter den rigtige bakke,
og det overhead der er ved at tage en ny bakke i brug.
Jo færre bakker, desto hurtigere søgning.

--
Vh Morten



Tomas Christiansen (03-04-2001)
Kommentar
Fra : Tomas Christiansen


Dato : 03-04-01 20:11

Morten Fast skrev:
> Det skal bakkemaster-klassen gøre. Den ved, hvilke bakker der er i brug,
> og hvilke bakker den kan sende hvilke stykker afsted til.
> Den sørger også for, at stykkerne har fået udpeget en bakke, inden
> de kommer ud på båndet.
....
> Helt sikkert. De to klasser er udelukkende til sortering af stykker.
> Det samlede system vil være væsentlig større.
....
> Jeg vil nok mene, at mange af de klasser du nævner,
> blot er funktioner på en større klasse.
....
> Man behøver ikke at tage ti bakker i brug, bare fordi man kan.
> Hvis een bakke er nok, så er flere bakker bare spild.
....
> Hvorfor tage objekter i brug, som du sandsynligvis ikke får brug for?

Jeg vil på ingen måde give dig uret - men giver heller ikke dermed mig selv
uret!

Min erfaring med objektorientering ligger stadig på et meget toretisk plan,
idet jeg ikke har brugt (læs: haft mulighed for at bruge) det særlig meget i
praksis, og kan derfor sagtens tænkes at være "over-ivrig" med at definere
klasser i forhold til hvad der rent praktisk er brug for. Jeg er spændt på
at høre hvad det hele ender med - hvis Bjarne vil lække lidt oplysninger til
gruppen undervejs i projektet.

> Det er en balancegang mellem hurtig søgning efter den rigtige bakke,
> og det overhead der er ved at tage en ny bakke i brug.
> Jo færre bakker, desto hurtigere søgning.

Det kan jeg overhovedet ikke forstå.
En af os må have misforstået hvordan stationerne med bakkerne fungerer.
Er det ikke bedre at stationerne er klar med tomme bakker INDEN der er brug
for den, fremfor at vente til at der er brug for dem? Eller er det i
virkeligheden fuldstændig ligegyldigt?

-------
Tomas



Morten Fast (03-04-2001)
Kommentar
Fra : Morten Fast


Dato : 03-04-01 21:21

"Tomas Christiansen" <toc@blikroer.removethis.dk> wrote in message
news:Ffpy6.464$PR2.26713@news.get2net.dk...
> Jeg er spændt på at høre hvad det hele ender med - hvis Bjarne vil
> lække lidt oplysninger til gruppen undervejs i projektet.

Også mig.

> Er det ikke bedre at stationerne er klar med tomme bakker INDEN
> der er brug for den, fremfor at vente til at der er brug for dem?

Jo, bestemt. Bakkerne skal fysisk være til stede på stationen.

Men for at have så få bolde i luften af gangen, tager systemet
ikke bakkerne i brug, før det er absolut nødvendigt.

Der bliver altså ikke dannet et objekt af klassen Bakke, før
fisken på ingen måde kan placeres i et eksisterende Bakke-objekt,
og på den måde er de ubrugte bakker ikke-eksisterende i programmet,
selvom de fysisk står klar på båndet.

--
Vh Morten



Bjarne Østergård (03-04-2001)
Kommentar
Fra : Bjarne Østergård


Dato : 03-04-01 23:29


"Tomas Christiansen" <toc@blikroer.removethis.dk> wrote in message
news:Ffpy6.464$PR2.26713@news.get2net.dk...
>
> Min erfaring med objektorientering ligger stadig på et meget toretisk
plan,
> idet jeg ikke har brugt (læs: haft mulighed for at bruge) det særlig meget
i
> praksis, og kan derfor sagtens tænkes at være "over-ivrig" med at definere
> klasser i forhold til hvad der rent praktisk er brug for. Jeg er spændt på
> at høre hvad det hele ender med - hvis Bjarne vil lække lidt oplysninger
til
> gruppen undervejs i projektet.

Det vil jeg helt bestem gerne, jeg har selv draget meget stor nytte af
deltagelse på denne NG
Faktisk er et af mine færdige programmer Safe PC født her på gruppen i en
diskution om at få VB til at ringe til en telefon og sende Sms.
Det og så det at jeg har en bror der ejer et vagtselskab gjorde at jeg fik
ideen til Safe PC, som er en tyverialarm der virker ved at den kan få
computeren til at ringe et telefon nr. op hvis nogen starter den eller hvis
man kommer til at bevæge musen, mm.
Har faktisk solgt rimelig godt så jeg skylder denne NG en del.


> > Det er en balancegang mellem hurtig søgning efter den rigtige bakke,
> > og det overhead der er ved at tage en ny bakke i brug.
> > Jo færre bakker, desto hurtigere søgning.
>
> Det kan jeg overhovedet ikke forstå.
> En af os må have misforstået hvordan stationerne med bakkerne fungerer.
> Er det ikke bedre at stationerne er klar med tomme bakker INDEN der er
brug
> for den, fremfor at vente til at der er brug for dem? Eller er det i
> virkeligheden fuldstændig ligegyldigt?

Sådan har jeg indtil nu grebet det an

Hver bakke har en variabel Station 0 til 9
Hver posision på båndet har ligeledes en variabel Bond0 til 9

Selv om der er flere pladser på båndet tælles variablen kun op hver gang der
også placeres et fiskestykke på pladsen og hver gang variablen når til 9
nulstilles den og næste plads får så nul igen

Hver gan et stykke sættes på båndet tages et billede med et kamera og
størrelse og vægt samt kvalitet kontrolleres. er det f.eks Bond5 tillægges
vægten af stykket nu variablen Bond5=Vægt

Ligeledes med stationerne, hver gang et stykke afleveres tælles deres
variabel op med vægten af det afleverede stykke.
Station3=Station3+ Bond5

Station3 er nu forøget med vægten af det stykke der var på Bånd pladsen
Bond5
Bond5=0

Når StationX har nået vægten inden for den tilladte tolerence køres bakken
væk og udskiftes og vægten på stationen sættes til 0

Station3=0

Egentlig ret enkelt at styre selve processen, men det er fordelings
algoritmen der er svær.

Jeg bruger arrys til at holde styr på de forskellige variabler og deres
tildelinger.

--
Med venlig hilsen
Bjarne Østergård
Gigasoft Danmark
www.gigasoft.dk
boe@gigasoft.dk
Tlf: 86 49 64 04









Tomas Christiansen (04-04-2001)
Kommentar
Fra : Tomas Christiansen


Dato : 04-04-01 13:16

Bjarne Østergård skrev:
> Hver bakke har en variabel Station 0 til 9
> Hver posision på båndet har ligeledes en variabel Bond0 til 9
>
> Selv om der er flere pladser på båndet tælles variablen kun op hver gang
der
> også placeres et fiskestykke på pladsen og hver gang variablen når til 9
> nulstilles den og næste plads får så nul igen

Betyder det, at hvis der skal en station/bakke mere på, så skal du omkode
dit program?

> Ligeledes med stationerne, hver gang et stykke afleveres tælles deres
> variabel op med vægten af det afleverede stykke.
> Station3=Station3+ Bond5

Hvad så hvis du har sendt 1 stykke afsted til Station9, som bliver fyldt op,
når stykket når derud?
Det er først når stykket når frem, at du tæller vægten med.
Kommer du du så ikke let til at sende flere større, og større stykker afsted
til Station9, i den tro at den ikke er fyldt op?
Resultat: Du starter en tom bakke i station 9 med et STORT stykke fisk!

> Jeg bruger arrys til at holde styr på de forskellige variabler og deres
> tildelinger.

Har du slet ikke overvejet en objekorienteret løsning?

-------
Tomas



Jane H. F. Vestergaa~ (03-04-2001)
Kommentar
Fra : Jane H. F. Vestergaa~


Dato : 03-04-01 21:54

Hej Bjarne
Jeg syntes det lyder som et spændende projekt.
Men der er en ting jeg ikke kan forstå (med fare for at blive skældt ud):
Det du laver er et styrings og overvågningsprogram i VB, med de fordele og
ulemper der er heri.
Hvad skal der ske hvis computeren er nede?
Kan der så ikke pakkes laks? (og kan jeg ikke få min søndags franskbrødsmad
med laks?
Jeg vil ikke sige noget om dine kodeevner, for dine produkter (gigasoft.dk)
ser fine ude.
Men er VB det rigtige at bruge til det?
VB er ikke real tids, og kan ikke overholde en svartid på 0,5 sekund 100% af
tiden.
Hvordan skal du kommunikere med Stepmotorene?
Du skriver via nogen I/O kort, har de en ActiveX du kommunikerer igennem, så
du ikke skal lave
din egen poller thread i VB (generelt noget gris at lave VB multithreaded),
eller hvordan (multi ActiveX!)?

Nej. Det jeg vil foreslå dig er at sætte en lille PLC på anlægget. De kan
fåes til små penge og kan snildt programmeres
til at løse opgaven (ja, okay snildt og snildt, logisk ihvertfald). Den skal
du så kommunikere med i VB (eller et andet stykke
overvågningssoftware!). PLC'er er er deterministiske, har en scantid på
under 0,5 sekund og er mere driftssikre end en PC.
PLC'en kommunikerer med Stepmotorene via nogen I/O moduler.

Jeg håber ikke du vil tage ovenstående ilde op.
Jeg har selv prøvet at lave styrings og overvågningsprogrammer og syntes
bestemt ikke
det er let så snart der skal kobles brugere på.

Jeg håber det bliver en succes og spørg endelig hvis du har andre problemer.
Nu så jeg først spørgsmålet efter det var løst.

Lige et generelt spørgsmål:
Er der flere automations folk der har svaret på Bjarnes spørgsmål?

mvh
Anton


"Bjarne Østergård" <boe@gigasoft.dk> skrev i en meddelelse
news:9a4mqg$2ggs$1@news.cybercity.dk...
> Hej jeg håber der er nogle kvikke fyre eller fyrinder der er gode til lidt
<<--SNIP




Bjarne Østergård (03-04-2001)
Kommentar
Fra : Bjarne Østergård


Dato : 03-04-01 22:55


"Jane H. F. Vestergaard" <janefNOSPAM@post.tele.dk> wrote in message
news:9add64$cfc$1@news.inet.tele.dk...
> Hej Bjarne
> Jeg syntes det lyder som et spændende projekt.
> Men der er en ting jeg ikke kan forstå (med fare for at blive skældt ud):
> Det du laver er et styrings og overvågningsprogram i VB, med de fordele og
> ulemper der er heri.
> Hvad skal der ske hvis computeren er nede?
Så kan maskinen ikke køre.

Det er min ide at det hele igangsættes, styres og afsluttes via en
brugerflade på en pc.
Men denne pc`s opgave bliver også kun at styre maskinen.
På sigt skal der udtrækkes og laves statistikker, stregkoder osv via samme
maskine, og overordnet vil de indgå i et netværk med andre lignende
systemer, samt internettet og man kan så sidde i kina og bestille en
produktion i skagen.
Med Kininesisk tekst og prise samt varedeklartion osv osv.
Men det er altså kun mine ideer.
Tænk hvis varehuset der sælger produktet på nettet kan indtaste de
leverancher de vil have i morgen og maskinen hos fiskefabrikken går så i
gang med at pakke nettop denne leverance, nødagtig som det enkelte varehus
ønsker.

Det kan jeg godt drømme lidt om. (Der må være nogle muligheder og fremtid i
det, (ellers er jeg da skør)
Jammen det er jeg jo

> Kan der så ikke pakkes laks? (og kan jeg ikke få min søndags
franskbrødsmad
> med laks?
Jeg håber da ikke mit program går ned ret tit. skulle da gerne være så
stabilt at du ikke kommer til at savne dine laksebrød.

> Jeg vil ikke sige noget om dine kodeevner, for dine produkter
(gigasoft.dk)
> ser fine ude.
Tak tak. Men området jeg her har kastet mig ud i er også delvis nyt for
mig, så lige i øjeblikket samler jeg al den info. jeg kan for at løse
opgaven.

> Men er VB det rigtige at bruge til det?
> VB er ikke real tids, og kan ikke overholde en svartid på 0,5 sekund 100%
af
> tiden.
Skulle egentligt ikke betyde så meget da jeg vil modtage et nyt signal hver
gang et nyt stykke er klar på båndet, og båndet skal da blot køre en station
frem hver gang. Opgaven for VB er at beslutte hvilken station der skal
modtage det nye stykke samt hvornår en ny bakke skal køres frem på en af
stationerne.


> Hvordan skal du kommunikere med Stepmotorene?
> Du skriver via nogen I/O kort, har de en ActiveX du kommunikerer igennem,

> du ikke skal lave
> din egen poller thread i VB (generelt noget gris at lave VB
multithreaded),
> eller hvordan (multi ActiveX!)?
Ja her er jeg ikke selv helt sikker på teknikken endnu, jeg leder efter det
bedste.

> Nej. Det jeg vil foreslå dig er at sætte en lille PLC på anlægget. De kan
> fåes til små penge og kan snildt programmeres
> til at løse opgaven (ja, okay snildt og snildt, logisk ihvertfald). Den
skal
> du så kommunikere med i VB (eller et andet stykke
> overvågningssoftware!). PLC'er er er deterministiske, har en scantid på
> under 0,5 sekund og er mere driftssikre end en PC.
> PLC'en kommunikerer med Stepmotorene via nogen I/O moduler.

Det bliver nok denne løsning, men tidsmæssig mener jeg VB er nøjagtig nok.
da der vil være 0,5 sek. mellem de enkelte stykker, det er skæretiden.
Og skæretiden vil afsende et signal om at båndet skal rykke en station frem
hver gang.

Fordi jeg har valgt VB har to årsager, det er det sprog jeg for nuværende
kender bedst, og det er utrolig nem at lave grafiske brugerflader i dette
miljø.
Jeg leger lidt med VS.net og sproget C# ellers må jeg ty til gode gamle C++
men det tager jo noget længere tid i dette sprog, og jeg er ikke så øvet i
C++

Jeg har kontaktet nogle firmaer som jeg tror har nogle PLC modeller jeg kan
anvende og som let integreres i VB.
Men har nogen nogle foreslag her vil jeg være meget modtageligt for ideer
til teknikken, jeg er lodt på gyngende grund her. men det hører vel hjemme i
en ande gruppe?

> Jeg håber ikke du vil tage ovenstående ilde op.
Nej da, mit mål er at løse opgaven så godt som muligt, og måske når jeg frem
til at jeg slet ikke magter opgaven.
Men så er det nu første gang, jeg kan være ret stædig når det gælder at løse
en opgav og det jeg ikke kan må jeg jo så set at få lært.
Ellers har jeg før brugt freelance hjælp, og det kan jeg jo gøre igen på
dette projekt.

Har lige brugt et par nætter til at læse om et begreb der hedder Temporal
Difference Learning en inteligent algoritme der bruges hvis en computer
skal lære og ud fra det lærte så skal kunne forudsige en ellers
tilsyneladende tilfældig rækkefølge.

Men du godeste, jeg opdagede blot at jeg har meget at lære om matematik
endnu. Gik ellers lige og mente jeg var en farlig karl.

Jeg forsøgte så at programere denne teori i VB. men det har jeg opgivet nu.
Uha uha den er ikke for folk der gik ud af tredje række i skolen.


> Jeg har selv prøvet at lave styrings og overvågningsprogrammer og syntes
> bestemt ikke
> det er let så snart der skal kobles brugere på.
Næh jeg er ved at gøre samme erfarring, men jeg har dog nu fået reglerne
blødt lidt op og ved lidt mere om kraven så jeg tror jeg har en foreløblig
løsningsmodel om en 8 til 10 dage.

> Jeg håber det bliver en succes og spørg endelig hvis du har andre
problemer.
Tak og hvis du har nogle erfarringer med Plc og VB vil jeg være meget
intresseret.

Måske er det skørt, men jeg overvejer faktisk at lave en model opstilling
med Lego Mindstorm (hedder det vist)

Er der nogen der har erfarring med dette, og kan det overhovedet bruges til
test af den her type?


--
Med venlig hilsen
Bjarne Østergård
Gigasoft Danmark
www.gigasoft.dk
boe@gigasoft.dk
Tlf: 86 49 64 04









Jane H. F. Vestergaa~ (04-04-2001)
Kommentar
Fra : Jane H. F. Vestergaa~


Dato : 04-04-01 15:13

Hej Bjarne

"Bjarne Østergård" <boe@gigasoft.dk> skrev i en meddelelse
news:9adgt8$638$1@news.cybercity.dk...
>
> "Jane H. F. Vestergaard" <janefNOSPAM@post.tele.dk> wrote in message
> news:9add64$cfc$1@news.inet.tele.dk...
> > Hej Bjarne
> > Jeg syntes det lyder som et spændende projekt.
> > Men der er en ting jeg ikke kan forstå (med fare for at blive skældt
ud):
> > Det du laver er et styrings og overvågningsprogram i VB, med de fordele
og
> > ulemper der er heri.
> > Hvad skal der ske hvis computeren er nede?
> Så kan maskinen ikke køre.
>
> Det er min ide at det hele igangsættes, styres og afsluttes via en
> brugerflade på en pc.
> Men denne pc`s opgave bliver også kun at styre maskinen.
> På sigt skal der udtrækkes og laves statistikker, stregkoder osv via samme
> maskine, og overordnet vil de indgå i et netværk med andre lignende
> systemer, samt internettet og man kan så sidde i kina og bestille en
> produktion i skagen.
> Med Kininesisk tekst og prise samt varedeklartion osv osv.
> Men det er altså kun mine ideer.
> Tænk hvis varehuset der sælger produktet på nettet kan indtaste de
> leverancher de vil have i morgen og maskinen hos fiskefabrikken går så i
> gang med at pakke nettop denne leverance, nødagtig som det enkelte varehus
> ønsker.
>
> Det kan jeg godt drømme lidt om. (Der må være nogle muligheder og fremtid
i
> det, (ellers er jeg da skør)
> Jammen det er jeg jo

Rigtig gode ideer. For at gøre det nemmere for dig vil jeg anbefale at kigge
på noget standard
software til netop det formål. Der findes flere på markedet (hvoraf jeg
varmt kan anbefale ...
(... indikerer det firma jeg arbejder for for, men det er ikke dk.marked)).
Med hensyn til kommunikationen mellem andre systemer og dit system syntes
jeg du skal prøve
at kigge på OPC (OLE for Process Control) som er en kommunikationsstandard
(ret god).

>
> > Kan der så ikke pakkes laks? (og kan jeg ikke få min søndags
> franskbrødsmad
> > med laks?
> Jeg håber da ikke mit program går ned ret tit. skulle da gerne være så
> stabilt at du ikke kommer til at savne dine laksebrød.

Det er nu heller ikke dit program jeg er bange for, men brugeren.

>
> > Jeg vil ikke sige noget om dine kodeevner, for dine produkter
> (gigasoft.dk)
> > ser fine ude.
> Tak tak. Men området jeg her har kastet mig ud i er også delvis nyt for
> mig, så lige i øjeblikket samler jeg al den info. jeg kan for at løse
> opgaven.
>
> > Men er VB det rigtige at bruge til det?
> > VB er ikke real tids, og kan ikke overholde en svartid på 0,5 sekund
100%
> af
> > tiden.
> Skulle egentligt ikke betyde så meget da jeg vil modtage et nyt signal
hver
> gang et nyt stykke er klar på båndet, og båndet skal da blot køre en
station
> frem hver gang. Opgaven for VB er at beslutte hvilken station der skal
> modtage det nye stykke samt hvornår en ny bakke skal køres frem på en af
> stationerne.

Okay. Det vil sige eventbaseret styring. Ingen endestop man skal tage højde
for.

>
>
> > Hvordan skal du kommunikere med Stepmotorene?
> > Du skriver via nogen I/O kort, har de en ActiveX du kommunikerer
igennem,
> så
> > du ikke skal lave
> > din egen poller thread i VB (generelt noget gris at lave VB
> multithreaded),
> > eller hvordan (multi ActiveX!)?
> Ja her er jeg ikke selv helt sikker på teknikken endnu, jeg leder efter
det
> bedste.
>
> > Nej. Det jeg vil foreslå dig er at sætte en lille PLC på anlægget. De
kan
> > fåes til små penge og kan snildt programmeres
> > til at løse opgaven (ja, okay snildt og snildt, logisk ihvertfald). Den
> skal
> > du så kommunikere med i VB (eller et andet stykke
> > overvågningssoftware!). PLC'er er er deterministiske, har en scantid på
> > under 0,5 sekund og er mere driftssikre end en PC.
> > PLC'en kommunikerer med Stepmotorene via nogen I/O moduler.
>
> Det bliver nok denne løsning, men tidsmæssig mener jeg VB er nøjagtig nok.
> da der vil være 0,5 sek. mellem de enkelte stykker, det er skæretiden.
> Og skæretiden vil afsende et signal om at båndet skal rykke en station
frem
> hver gang.
>
> Fordi jeg har valgt VB har to årsager, det er det sprog jeg for nuværende
> kender bedst, og det er utrolig nem at lave grafiske brugerflader i dette
> miljø.
> Jeg leger lidt med VS.net og sproget C# ellers må jeg ty til gode gamle
C++
> men det tager jo noget længere tid i dette sprog, og jeg er ikke så øvet i
> C++

Eventuelt kunne du lave selve styringen i C/C++ og lave din brugerflade i
VB.
Din kommunikation mellem dit C-modul og din VB brugerflade kunne så være
OPC (COM/DCOM/COM+).

>
> Jeg har kontaktet nogle firmaer som jeg tror har nogle PLC modeller jeg
kan
> anvende og som let integreres i VB.
> Men har nogen nogle foreslag her vil jeg være meget modtageligt for ideer
> til teknikken, jeg er lodt på gyngende grund her. men det hører vel hjemme
i
> en ande gruppe?

Findes der en anden gruppe til det?

>
> > Jeg håber ikke du vil tage ovenstående ilde op.
> Nej da, mit mål er at løse opgaven så godt som muligt, og måske når jeg
frem
> til at jeg slet ikke magter opgaven.
> Men så er det nu første gang, jeg kan være ret stædig når det gælder at
løse
> en opgav og det jeg ikke kan må jeg jo så set at få lært.

Stædighed er en god ting.

> Ellers har jeg før brugt freelance hjælp, og det kan jeg jo gøre igen på
> dette projekt.
>
> Har lige brugt et par nætter til at læse om et begreb der hedder Temporal
> Difference Learning en inteligent algoritme der bruges hvis en computer
> skal lære og ud fra det lærte så skal kunne forudsige en ellers
> tilsyneladende tilfældig rækkefølge.
>
> Men du godeste, jeg opdagede blot at jeg har meget at lære om matematik
> endnu. Gik ellers lige og mente jeg var en farlig karl.
>
> Jeg forsøgte så at programere denne teori i VB. men det har jeg opgivet
nu.
> Uha uha den er ikke for folk der gik ud af tredje række i skolen.

Lyder som noget jeg tog et kursus i en gang. Kurset hed noget med Fuzzy
Logic.
Jeg kunne implementere det i VB, men det koster computertid at lave sådanne
beregninger.
Hvis det skal bruges skal man vel egentlig også have nogle flere parametre
(fiskens initiale størrelse! og ...).


>
>
> > Jeg har selv prøvet at lave styrings og overvågningsprogrammer og syntes
> > bestemt ikke
> > det er let så snart der skal kobles brugere på.
> Næh jeg er ved at gøre samme erfarring, men jeg har dog nu fået reglerne
> blødt lidt op og ved lidt mere om kraven så jeg tror jeg har en foreløblig
> løsningsmodel om en 8 til 10 dage.
>
> > Jeg håber det bliver en succes og spørg endelig hvis du har andre
> problemer.
> Tak og hvis du har nogle erfarringer med Plc og VB vil jeg være meget
> intresseret.

Jeg har en del erfaring med begge.

>
> Måske er det skørt, men jeg overvejer faktisk at lave en model opstilling
> med Lego Mindstorm (hedder det vist)
>
> Er der nogen der har erfarring med dette, og kan det overhovedet bruges
til
> test af den her type?
>

Lego Mindstorms robotten er faktisk en lille PLC og kan programmeres på
samme måde.
Det vil sige at du ikke behøves at bruge det medfølgende logik program til
at lave mere avancerede ting
(jeg tror ikke det kan klare det).



>
> --
> Med venlig hilsen
> Bjarne Østergård
> Gigasoft Danmark
> www.gigasoft.dk
> boe@gigasoft.dk
> Tlf: 86 49 64 04
>
>
>
>
>
>
>
>


mvh
Anton



Søg
Reklame
Statistik
Spørgsmål : 177558
Tips : 31968
Nyheder : 719565
Indlæg : 6408929
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste