1 verzió

Köszi! Lehet, hogy ennyit illendő megtenni, miután...

Lehet, hogy igazad va, mert ha egy TCP-IP-t feldobva, tényleg működik, akkor az valóban egyszerűbb, még ha esetleg a többit C-ben is teszed hozzá!

Az fcd-hez még annyit, hogy inkább a sorban lévő st-t érdemesebb kijavítani cr-re, mint utánafűzni a helyes parancsot, mert az egy plusz utasítás feleslegesen. Az eredmény persze ugyanaz. Tényleg hasznos, hogy lehet ilyet csinálni...

Köszi de sajnos nem tudom megnyitni nekem 4.2.3.58 van.

Megnéztem néhány fcd-t, mindben hibás a beállítás!
Azt egyébként nem értem, hogy a Microchip miért nem rendelte össze a két funkciót inverz logikával. Mert ha belső oszciforrást választok, semmi értelme a külső oszcinak. Habár valami kinti dolognak jó lehet külön is. Nem tudom...

4-es verziósra

Köszi!

Igen.
Viszont azt vissza kell vonjam, hogy át lehet nevezni az fcd-t. Nem lehet, nem tudja kezelni sajna. Viszont a régit átnevezve, elmentve pl *.fcdori ra, lehet sajátot kreálni, ami állandó, de visszaállítható a mentésből.

Megnézem a projecthez tartozó megoldást is, köszönöm! Megjegyzem, hogy ha valaki ilyen szinten ért a rendszerhez, mint te, akkor tényleg minden megoldható, máskép nem, teljesen C blokkokból fog felépülni a kód!

szerk: Na megnéztem, ezt kerestem, ezzel tényleg meg lehet oldani az ilyen alap problémákat!

Ne haragudj simpi de nem értem.Tudnál feltenni egy példát?

CCP2 Capture módhoz van előre gyártott modul?

Ez eddig oké de hogy tudok negatívba is mérni?
Én úgy számoltam hogy 2,5 referenciával -20C-tól +82C fér bele 0.25C felbontással.
Amit elsőként feltettem az ezt csinálja csak tizedek nélkül.

Miért nem nézed meg az enyémet? Az tudja a negatívot is!

Néztem csak nem értem.A tied 0-ás AD értéknél -0.5C 600-as AD értéknél meg 1.0C

Aha közben megvan, hiányzott egy százas szorzás.
Így már jobb a helyzet.
Köszi!

A bemenetnél ahol elosztod 4/el ott töröld az osztást és szorozd meg 25-el és akkor nem kell annyi számítás.

Igazad van,átírtam.

Már csak annyi baja van hogy túl sűrűn frissíti a kijelzőt ami villogáshoz vezethet, ennek elkerülése érdekében csak akkor írasd ki az értéket újra ha változott!

Ja igazad vagyon.

Hogyan lehetne leszimulálni egy CCP2-es Capture megszakítást? Lefutó élre van konfigolva. Bármit csinálok, nem fut bele a megszakítás Makróba...

Ha írtál bele C-t, gondolom igen, akkor flowban nem tudod szimulálni, csak külső szimulátorban.

Szomorú vagyok, de köszönöm a választ!

Tudom ez a program hiányossága , én proteust használok párhuzamossan a flow-al, bevált, és ha nem *.hex-t töltöm be hanem a /.cof-t még leskelődhetek is a program futása közben.

Az egyedi megszakítási beállítások nem újak, még sem tudja szimulálni. Kipróbáltam egy CCP2 Capture kódot, egyedi megszakítással, valóságban működik. A gond, hogy hogyan lehet ezt beilleszteni egy rendszerbe, ha véletlenül ettől működik a kód többi része. Mindenesetre elég sokat kérnek érte(60ezer körül), hogy végül nem is teljes funkciós. Nem a TCP-IP-t és társait kéne erőltetniük, hanem először azokat az alap funkciókat, amik a PIC-ben vannak! Kicsit csalódott vagyok, többre számítottam. Így nem tudom van-e értelme ebben indítani egy közös projectet az egyszerűség oltárán. Nekem már egyszerűbbnek tűnik a C, ha nem akarok egzotikus modulokat használni. Persze tök jól néz ki feldobálni LCD-t gombokat, LED-eket, tényleg érdekes, de nekem pont egy motor indításhoz kell a CCP2... Na majd lesz valahogy...

Hali!
Pont ezért *

Na igen, ki mire használja...

Speciel a szimulációt sose használtam, nem is tudom működik-e bármely programomon. Szerintem nem, mert sok egyedi megoldást, kapcsoló vezérlést, vagy ledvezérlést használok és nem modult.

Viszont azt nem értem, ha Te ennyire tudsz C-ben programozni minek neked a Flowcode?
Kicsit visszalépésszerű, nekem. Ha tudnék ASM-ben, C-ben programozni, nem érdekelne.

Bár olvasgatva a beszélgetést, a program működik, csak a szimuláció nem. Miért ennyire fontos a szimuláció? Az csak szimuláció, akár milyen pontos is, nem valós így lehet eltérés.

Próbáljunk a lényeggel foglalkozni, az tanulságosabb mindenki számára.
Sok ezer program van, annak mindnek van olyan hibája, hiányossága amit szóvá lehet tenni, mégis használják, ezzel együtt kell élni, tökéletes mint olyan nem létezik, ez sem az, és ebben a kategóriában sem tudnék (más sem) mondani olyant amibe ne lehetne hibát találni. Ez alól a C, ASM, MPLAB sem kivétel, szóval erre felesleges a szót pazarolni.

Szia! Írtam korábban, nem magam miatt. Azért lenne jó a szimuláció, hogy könnyebben meg tudjam értetni a programrészek működését, hogy utána maguk tudjanak tovább haladni, összeollózni azokat.

A lényeg mellett akarsz elmenni. A folyamatleírás lényege, hogy egyszerű, sokak számára közérthető. Ha ilyen alapvető problémák akadályozzák a haladást az nem a folyamatleíró nyelv hibáját jelenti, hanem a fejlesztőgárda hiányosságait.
Nekem a PLC-k után nem kell megérteni a nyelvet, csak a fejlesztői környezetet kell megismernem, de egy PLC fejlesztői környezete nem engedhet meg ilyen nagy hiányosságokat.
Abban igazad van, hogy nem érdemes szapulni a nyelvet, de itt nem a nyelvet, hanem a fejlesztő környezet hibáit tárgyaltuk(legalább is mi), ami szorosan a témához tartozik!

Proteus, abban meg lehet érteni, arra találták ki. De van azon kivül is még x tucat erre való program. Nem értem ez a probléma miért kötődik a flowcode-hoz ?