• Úvod
• Excel návod
• Excel šablony
• Nástěnka
• Mobility
• Tipy na výlet
• Galerie
• Fórum

MS Excel

Téma: REFPROP - zápis hodnot do buněk ve vba

Zaslal/a desairo 7.8.2015 11:22

Dobrý den,
před lety jsem si pořídil software REFPROP (pro termodynamické výpočty), který lze pomocí REFPROP.XLA propojit s excelem. Výpočty v rámci listu i ve vba fungovaly výborně ale po přechodu z win xp, excel 2010 na win 7 a excel 2013 přestala fungovat moje makra. Nyní se k výpočtům znovu vracím a rád bych makra zprovoznil. Zdá se, že REFPROP počítá ve vba správně ale vypočtené hodnoty se nedaří zapsat do buněk v listu. Pro názornost uvedu primitivní příklad:

Dim Teplota_C As Double
Dim Teplota_K As Double

Private Sub CommandButton1_Click()

Teplota_C = Temperature("mdm", "crit", "si with c")

MsgBox (Teplota_C)
ActiveSheet.Range("a1") = Teplota_C

ActiveSheet.Range("a2") = "ahoj"

Teplota_K = Teplota_C + 273.15
ActiveSheet.Range("b1") = Teplota_K
MsgBox (Teplota_K)

End Sub

Teplota_C se odvolává na funkci REFPROPu, (která má spočítat kritickou teplotu MDM v jednotkách soustavy SI), a skutečně jí spočítá správně (290,94°C) a uloží do proměnné Teplota_C (potvrzeno přes debug/run to cursor), zobrazí se MsgBox (Teplota_C) se správným údajem ale do buněk A1 a B1 se nic nezapíše, dokonce ani do buňky A2, která s výpočtem REFPROPu nesouvisí. Přitom Teplota_K je spočtena správně a zobrazí se i MsgBox (Teplota_K) se správným údajem. Pokud bych pro výpočet proměnné Teplota_C nepoužil funkci REFPROPu (ať už temperature nebo jakoukoli jinou) ale vlastní rovnici, pak zápis do buněk proběhne správně. Zkoušel jsem proměnnou i úplně odstranit (např. ActiveSheet.Range("a1") = Temperature ("mdm", "crit", "si with c")) ale chová se to stejně…

Předem děkuji za případné nápady.

Zaslat odpověď >

---

Strana:  « předchozí  1 2

desairo(10.8.2015 12:38)#026191

Tak vyřešeno, doplněk sice aktivní byl, ale něco s ním nebylo v pořádku (po změně koncovky na XLS nešel otevřít - ani na PC, kde nikdy předtím nebyl). Od vydavatele softwaru jsem získal nový soubor REFPROP.XLS, převedl na doplněk (rovnou xlam - ?) a vše funguje jak má.
Děkuji všem za podnětné příspěvky.

PS: když už jsem to tu nakousl, poprosil bych vás ještě o názor na rychlost makra:
Makro načte z listu cca 50 vstupních hodnot, provede matematické výpočty (cca polovinu přes REFPROP, zbytek samo), vypočtené hodnoty zapíše do listu (cca 350 až 400 tisíc čísel – každé asi 15 znaků) a vykreslí graf (cca 60 křivek). K zápisu dat používá příkazů ActiveCell.Offset a With ActiveCell…Offset. Po opravě doplňku makro trvá cca 32s + 3s na vykreslení grafu. Výpočty v REFPROPU jsou relativně složité, přesto si myslím, že většinu času zabere zápis do listu. Myslíte si, že by použití jiných příkazů pro zápis dat (jako třeba v předchozím příspěvku zmíněný Array), mohlo běh makra výrazněji zkrátit?citovat

eLCHa(10.8.2015 13:05)#026192

Abychom mohli správně odpovědět, bylo by třeba vidět ten kód.

Samozřejmě základem je co nejnižší počet zápisů na list (např. pomocí zmíněného pole). Pokud je nutno zapisovat po jedné buňce (což většinou není) je možné zvážit vypnutí kalkulací. Mno a vypnutí překreslování také dost pomůže.citovat

Vovka(10.8.2015 13:47)#026197

to desairo: převod doplňku z xls na xlam je zcela regulérní obrat, pokud Excel nenajde ve zdrojovém xls nějaké nekompatibility s ribbonovým Excelem. To se ve vašem případě zřejmě nestalo, takže vše nejspíš bude běhat správně.
S odpovědí eLCHa na možnost zrychlení se zcela ztotožňuji. Vypnutí všech přepočítávacích a přezobrazovacích akcí je tím prvním a základním krokem ze zrychlení. Pro posouzení, co by šlo ještě zrychlit, by bylo nutné vidět, jak je kód napsaný. Mne 35 sekund na provedení popsané akce zas tak moc neděsí. Ale stejně tak by to třebas mohlo běžet podstatně rychleji. Bez znalosti napsaného kódu to ovšem zodpovědně neposoudí nikdo!citovat

desairo(10.8.2015 15:52)#026205

V příloze zasílám kód k nahlédnutí. Zvážím ještě nahrazení některých proměnných typu double za single a celkové omezení množství výpočtů (pro zobrazení v grafu jsou výsledky asi zbytečně přesné).

Příloha: 26205_desairo.txt (33kB, staženo 21x)

citovat

Vovka(10.8.2015 17:17)#026207

Ten kód je na můj vkus napsaný velmi exoticky. Očekával jsem rozsáhlé cykly, místo nich jsem našel zamilované hraní se zápisem ActiveShett.Offset, zato žádná pole ani definované oblasti na listu. Zápis by šlo několikanásobně zkrátit, ale významné zrychlení algoritmu by to nejspíš nepřineslo.
Přechod od Double k Single by přinesl jen nepatrné zrychlení, které vůbec nestojí za námahu. Zato zmenšení rozsahů v datech pro grafy ve vašem případě skrývá velký rychlostní potenciál. Deset tisíc prvků v sériích je podle mého soudu řádově vyšší, než lze na listu odlišitelně zobrazit. Cesta redukce rozsahů dat pro grafy je podle mne tím správným krokem za zrychlením výpočtů.citovat

Vovka(10.8.2015 17:31)#026208

Omluva: samozřejmě jsem měl na mysli obrat ActiveCell.Offset, kterými se kód hemží.citovat

elninoslov(11.8.2015 11:37)#026211

Dešifrovanie takto dlhého kódu je na hranici možností, ale kompletné prekopanie kódu na zapisovanie poliami, je bez reálnych dát v takto rozsiahlom kóde, s takým obrovským trafikom, s vypočítavanými pozíciami z premenných, množstvom premenných, a pritom sa nepomýliť a nedopliesť niečo, JE NEMOŽNÉ !. Urobil som Vám to niečo za polovicu. Neručím za to či je všetko správne, pretože to dávam čisto z hlavy, nieje na čom testovať (a verte, že takéto niečo JE potreba testovať, každý krok, napr. na pretečenie polí). Dalo by sa to ešte skrátiť, napr. vynechaním t1,p1,s1 ... tieto hodnoty by sa vo výpočtoch rátali rovno z poľa, výpočty by sa ukladali rovno do polí a nie najskôr do premennej a tá do polí.
Tam kde je to prvé On Error Resume Next (tesne pred koncom mojej úpravy) som už pole nedával, už sa mi nechcelo.

Příloha: 26211_f3c_x3.rar (40kB, staženo 21x)

citovat

Strana:  « předchozí  1 2

Uživatelské menu

Nejste přihlášen(a)

• přihlásit
• registrace

\n

Menu

On-line nástroje

Formulář Faktura

Aktivní diskuse