Dec.30 Stacksize

This post documents information from studying stacksizes, because the choice of the AVR thread stacksize (2048) was not clear.  
Summary:

used AVR stacksize =2048 is:
    min  < avr < typical 

  1120 < 2048 < 2400

So 2048 is probably ok.  
2048/size(int) = 2048/32 = 75 int variables would be allowed.
Since minimum is 1120, then 2048-1120=928 ==>  928/32= 29 automatic variables could be used by receiveThread function.  

.
Background: AVR control code was written in C. Updating it from C to C++, it  needed the most care due to its direct HW communication between the ARM and AVR.  There may still be improvements, but changes need to be made carefully to not break working code.
.
Studying the code during the code review update.
1. Why the stack size of 2048 was chosen?
Answer: Value used in sample code in eCos Book:: Embedded SW Dev  with eCos p.111 Code Listing 6.1: Thread Initialization Example 
.
2. Is it really the best stacksize for the avr communication thread?
Still unknown, but the min stacksize and typical stacksize suggested via the eCos include comments and other references are:
.
p.117 ecos reference explains the constants used for CYGNUM_HAL_STACK_SIZE_MINIMUM and CYGNUM_HAL_STACK_SIZE_TYPICAL stacksizes and were found in  hal_arch.h. The caclulated values are:

CYGNUM_HAL_STACK_FRAME_SIZE = (4 * 20) = 80
.

CYGNUM_HAL_STACK_INTERRUPT_SIZE=

((4 * 20) + 2 * CYGNUM_HAL_STACK_FRAME_SIZE) =

((4 * 20) + 2 * (4*20) = 240
.

CYGNUM_HAL_MAX_INTERRUPT_NESTING = 4

.

CYGNUM_HAL_STACK_SIZE_MINIMUM =

        (CYGNUM_HAL_MAX_INTERRUPT_NESTING * CYGNUM_HAL_STACK_INTERRUPT_SIZE 

         4     *     240

         + 2 * CYGNUM_HAL_STACK_FRAME_SIZE) + 2 * 80

         = 4* 240 + 2*80 = 1120

.

CYGNUM_HAL_STACK_SIZE_TYPICAL = (CYGNUM_HAL_STACK_SIZE_MINIMUM 

         + 16 * CYGNUM_HAL_STACK_FRAME_SIZE)

= 1120 +16*(4*20) =2400

.

Info from comments;

// ...Idle thread stack should be this big.

.

//    THESE ARE NOT INTENDED TO BE MICROMETRICALLY ACCURATE FIGURES.

//           THEY ARE HOWEVER ENOUGH TO START PROGRAMMING.

// YOU MUST MAKE YOUR STACKS LARGER IF YOU HAVE LARGE "AUTO" VARIABLES!

.

// This is not a config option because it should not be adjusted except

// under "enough rope" sort of disclaimers.

.
This leads to the Summary at the top of this post.

Dec.29 + Jan. 6.AVR Firmware version FB

For complete access to all information in the Battery word, a Function Block to access AVR firmware major and minor version has been created. It will not be automatically compiled by LMS cmake, but commented out by default.

Curious what versions of the AVR firmware version of various LMS will be. (will post test here)


Jan. 6 AVR firmware version # is all zeros.
Jan. 23 AVR FB abandoned because we do not need the information and it would never be used.

Dec.26 Battery FB start

Lego original Battery info documentation:
Battery info is part of the data recieved from the AVR as explained on  p.20 in  Lego Mindstorms NXT (TM)  Hardware Developers Kit 
Battery word contains the 

• voltage (mV) = bits 0-9 * 13.848
• not supporting float so multiply by 1024 * 13.848=  14180 then divide by 1024
• alternative: would be to just use relative power of 0-1023
• accu pack inserted bit (bool)  bit 15
• The accu pack has peg-like tab that pushes battery setting, when its inserted.
• avr firmware major.minor version (xx.yyy) bits 13-14 major; bits 10-12 minor
• AVR firmware version will be given its own FB if its ever needed.

Interesting lms Battery links:

Battery discussion in thenxtstep blog

Interesting study of NXT battery power levels:

Dec.26's Nov.29 Code Review update

General updates:

• in tests put constant first so never accidental assignment (if (0==x)... )
• use simple types (int, unsigned int, bool, etc) instead of forte or cyg types
• Changing cyg_bool to bool caused motors to stop working since cyg_bool=int
• static variables  in .cpp should be private member variables in h file
• when static variable address is passed to thread it must be in .cpp file 
• still looking for more eloquent way to do this
• if return will never be checked, then return changed to void
• delete extra comments with background information only

Not yet implemented:

• rename L_AD (analog digital sensor) to L_AI (analog sensor input)
• rename L_LED (sensor led output) to L_DO (digital sensor output)
• change from F_GT_UNIT to ../IEC61131-3/Functions/SelectionComparison/Comparison/F_GT 
• Using Forte-IDE 1.0 due bugs in dev IDE which cause types to disapper

Partly implemented:

• use { }s for all if and else causes, so to prevent possible errors from  debug prints 

Additional updates: 

• Changed motor max to 3 from 4 and padded the AVR buffer by 1.

Dec.20+ LMS Nov.29 Code Review status

This post is needed because LMS motors do not work with Nov.29 Code review changes.
Dec.24: Motor Problem cause: changing cyg_bool to bool, which is really int.
Specifically:
  cyg_bool is:   typedef  cyg_halbool            cyg_bool 
  cyg_halbool is:    # define cyg_halbool int
Code that translated cyg_bool=int from int to simple bool was deleted as unnecessary during code review. This broke the motor code.
Oct.28 LMS FBs fully tested
Nov.29 LMS code review Change Summary:
* more naming convention changes
* change from eCos ARM and Forte types to simple types like int where possible
* no return function value if it will never be checked
* one return. set a variable rather than return. This helps the optimizer
* AVR changes to be completed
Nov.30 LMS -O0 and current LMS too large
Dec. 1  prelim LMS with current FORTE tests and current FORTE IDE 
...but current Forte grew and caused forte.bin with -O0 to be too large for LMS and dev Forte IDE had problems

LMS after code review: 
* LED works

* TOUCH doesn't - needs F_GT - bug report written ... can regress to UINT_GT, but....

* BUTTON works

* MOTOR is not consistent... seems to need the power to be large enough to move, if too little power, might not turn at all.   motor  code changes were in AVR.

* LT sensor read needs F_GT to work, too.

* (OFF untested with new code, but assume works - no changes)

Dec. 2  Tested individual Nov.29 FBs with current Forte
* Changed to ../IEC61131-3/Functions/SelectionComparison/Comparison/F_GT from F_GT_UINT for LC_TOUCH
* Motor FB not working with lower power
Dec.14 Finished testing builds of various smaller eCos versions
Dec.20+ with current Forte, IDE 1.0 (and F_GT_UINT)
* -O2 with Oct.28  LMS code unchanged - full regression test works (sensors,motor (10%),buttons, off)
* -O2 with Nov.29 LMS code - Sensor FBs and Off work.  Motor FB does below 40% power and then slow.
* Currently adding the Nov.29 Code Review code to the working Oct.28 code a little at a time - All  FBs work with additions. Last is adding the CL_AVR_ctl changes, because there were so many adding in related changes and testing.

Dec.14 eCos Build+thumb

Around Dec.1 it was found the current forte.bin was now too large for the LMS.
The past way to make forte.bin smaller was to make eCos smaller by pruning features consided unnecessary. The LMS eCos build(s) came before me and this is my first eCos build.
    However it has never been built using Thumb instructions, which could almost half the size since Thumb instructions are 16 bits rather than 32 bits. But forte can't be compiled for thumb instructions if eCos isn't also configured for thumb instructions.
    My first own eCos configuration:  change to  -mthumb and -mthumb-interwork.  Then compile and test forte with these same options.
.
First thumb test LMS regression test results:
(LMS regession test: touch, light+led, motors, buttons)
1.works!  LMS forte (-O0) with IDE 1.0 
2. no!  LMS forte (-O2) with IDE 1.0 
** doesn't even register with device manager as an eCos device
.
eCos Build Process:
0. Follow instructions in ..\src\modules\lms\lms_ecos\readme_lms_ecos.txt
.
Using ecos centric configtool:
1. open repository
** 1st time:  Tool asks for eCos source file directory
** 2nd time: build --> repository.. --> enter eCos source file directory
2. open the .ecc file from forte hg
** file --> open  (select file with .ecc)
3. generate build tree
** build--> generate build tree
4. build lib
** build --> library
.
Via eCos Hal --> ARM architecture: checked Thumb options
.
Useful Links:
Config Tool: http://www.ecoscentric.com/devzone/configtool.shtml
Source: ftp://ecos.sourceware.org/pub/ecos/releases/ecos-3.0/ecos-3.0.cygwin.tar.bz2
or  ftp://mirrors.kernel.org/sources.redhat.com/ecos/releases/ecos-3.0/ecos-3.0.cygwin.tar.bz2

eCos Docs page: http://ecos.sourceware.org/docs.html

How to build: Configuring and Building eCos from Source

Nov.17 + Dec. 19 Line Follower revisted

Dec.19 Note:
It was hoped this post would be finished when Line Follower apps were tested, but once again Forte with needed LMS FBs is too large. More coming after making forte.bin smaller.
Currently several forte Line Follower apps are finished waiting to be tested.
.
Nov.17
Line Follower app design notes
The first try at a Line Follower used GT= 2 point controller and then a  hysteresis.
.
The current try would like to try to automatically calibrate the light (off line) and dark (on line) following the line edge as suggested in A PID Controller For Lego Mindstorms Robots.
.
The approach is to use increasing better controllers:

• 2 point controller via  F_GT FB.
• Hysteresis since need UINT or INT must be created
• PID 

The threadhold / setpoint has be calibrated and it  would be nice if it could adjust itself while running to handle lighting changes and shadows.

.

Open is how to find the set point.

Nov.14 Comments in 4diac-ide

This entry is a start to review and try to make info seen consistent in 4diac-ide.


How can "things" be commented in 4diac-ide? Under properties. 

Which properties?  comment, description  misc> instance comment

Is there a consistent way to comment your own and see for existing "things"?

First:

What are all of the "things"?  Which properties do they use? Where are they seen?

• System Configuration  
• Device Instance
• Resource 
• description seen in Palette
• (How do device and resources get added to this palette?)
• Seen: 
• Mapped To: .
• Deployment under Resource selection  
• Properties - Deployment  
• next to Device Instance name 
• Misc - Profile = Holobloc ?? never shown
• Function blocks (FBs)
• FB type name
• Properties 
• Comment 
• seen - FB Palette if settings=details
• often default value like "Basic Function Block"
• Description
• ?? never shown
• In Application: mouse over both
• FB instance name
• FB type name
• see:FB type name / System name/ Application name / mapped t
• Interface 
• events and data variables
• Properties: comment 
• seen - mouse over in application
• event "with" data connections
• seen - mouse over in application
• Applications
• FB instances
• Properties: misc comment 
• seen - mouse over in application
• Connections between FBs
• Properties:  misc comment 
• seen - mouse over in application
• Sub-applications
• seen: mapped to
• Notice not there like with FB
• subapp window
• FB instance name
• Less info than FB in application without a subapp like no
• Application name
• FB type name
• mapped to 
• Notice not there like with FB

Nov.11 Binary counter

A friend likes to use binary clock to interest and teach binary in elementary school. This app just counts up to 16 in binary. Seemed like a good finger / test exercise, but also shows the IEC61499 could be used to teach simple circuits.

Full application, hopefully resembling simple circuits

Same application using sub-apps:(dashed lines really solid)

• FB_ADD, FB_XOR had to be added (to math.FBRT).  FB_OR and FB_NOT were added for completeness. Since the FBRT.jar has FB_ADD and 3 basic logic FBs and their interface matches the IEC61131 3. SelectionComparison.BitwiseBoolean FBs, (but not their names) only cloning these FBs was needed. 
• This app could be used with LMS light sensors and forte, not just FBDK FBs and display on a PC.
• To further test sub-applications, the application was grouped into sub-apps. This worked, but the tries that did not work are at the end.

The same working application mapped and working:

To work correctly sub-apps must be mapped both:

1. inside each sub-app

2. in application

Sub-app funnies: 
Notice the sysconf window. The connection to the init has to be the FB inside the Sub-App. Connections to cold/warm to subapp event is not allowed. But due to requiring both mapping the sub-app FBs show is no connections among each other. And on top is the regular app view with sub-app and connections.

Previous try was worse. The sub-apps were just mapped inside the sub-apps, but not the application: (unmap inside the sub-app must be done 1 FB at a time.)

First try, the sub-apps were only mapped inside the application. In sysconf the cold/warm connectors could not be connected to a subapp connector. (Screen shot did not capture the cursor with the forbidden circle with slash).

Nov.10 fordiac tutorials

Idea is to create tutorials that help those who know IEC 61499 standard get started with fordiac.
The last 2 years hysteresis (FBDK IDE)  has been used with Masters level Elec.Eng. and touch on/off LED and flip-flop blinky with first semester Elec.Eng. (LMS with 4diac-IDE).


First idea was hysteresis problem for those who know IEC 61499. However a minor detail was forgotten, this lab always used FBDK in the past. To use create new FBs with fordiac and use FBDK HMI in /out FBs means even the first applications have to be distributed. So this has been abandoned for the moment.


Instead a tutorial which explains the existing application that comes with 4diac-ide was created:
Getting Started: Using TestSystem supplied   (link on fordiac dev wiki main page)


Flip-Flop tutorial to explain both fordiac and IEC 61499 application and FB development is in progress.

• Flip-Flop Creating an application is ready to be tried.
• Flip-Flop Application Structuring with Sub-Applications - has shown up some funnies / inconsistencies in the IDE. This needs to be tested with more current versions of the IDE
• Flip-Flop Developing Function Blocks is in progress

Oct.27+ Video Tutorials

Enchanting project tutorials are mostly videos and very helpful.
So started experimenting with screen capture tutorials for IEC61499 / fordiac


Screen capture: CamStudio as .avi, but can easily be converted to Flash (.swf)
   Tutorials and other documentation online is helpful, like using 20 frames/sec.
   However the video file is still large, so still learning the best options to record.


Editing:  Windows Movie Maker for now.


More to come....

Oct.25 Follow-ups

3 Freshman EE labs (1 hour)
Today was the last of the 1 hour labs. Today two groups finished all exercises and had time to add in motors. An existing Lego "car" robot and mechanical arm robot has their motors plugged into the LMS with forte.  They first tried 1 motor and then had it go in circle with 1 motor forward and 1 motor backwards. The mechanical arm just rotated up /down.


Last week no one finished. Difference was this week started switching the LED on and off via touch and then adding in a second switch and SR FBs.  The last group had problems understanding/ remembering to take out the battery to turn off the LMS. Fortunately this has been changed to the push of a couple of key leading to the next item...


Buttons (and AVRctl):

• Debouncing was changed to only use the value.
• Decoding is only done now in the Button FB
• Right+Left Keys now turn off the LMS
• Code clean-up to match standards - so code review time again

Clock time differences:
The ecos numerator and denominator were changed to match the clock times for LMS found in both Lego and Lejos firmwares. New ecos is still being evaluated.

Oct.19 Freshman EE Lab

The following exercises were used with freshman electrical engineers for 1 hour lab.


Some of the basic concepts touched on were:

• Use of Touch sensor for control
• A blinky LED is to electrical engineering like Hello World is to  programming.
• Flip-flop via blinking LED, plus Set/Reset and Switch FBs
• Trigger on raising edge (turned on) and trigger on falling edge (turned off)
• In Ex.4 reuse of patterns to do something similar

Ex.1 was explained, most finished Ex.2, half made progress on Ex.3, but none fully finished.


Ex.1 Press Touch and LED comes on

Ex.2 Press Touch and LED starts to blink

Ex.3 Press Touch and LED starts to blink, then release Touch and the blinking stops

Ex.4 Press Touch blinking starts, then press Touch a second time and the blinking stops

Oct.15 Regression tests

Finally buttons and avr code clean-up is hopefully finished.

Alot of the testing was to be sure nothing broke due to clean-up.

Regression Test 1: Test as many LMS FBs as possible

• Touch turns on LED 2
• Enter turns on Motor and an LED 1
• If LED1 measures enough light then LED3 comes on. 
• If turn LED2 and point at LED1, then LED3 comes on.
• Or if room very light try putting finger over LED1 and LED 3 should go off
• Very sensitive to room's lighting and might flicker if room light close to light boundary
• Left +Enter turns off

Regression Test 2: Test all buttons

• Change numbers to test button combinations

Regression Test 3: Test Port errors are handled correctly

• Order of the inits is important so the errors / LEDs expects turn on or are ignored

Sept.29 Clean-up and Motor ports

Code clean-up time. 

AVR Control class still needs some more clean-up, but otherwise FBs are used now.

1. CL_Button and CL_SensorPortMgr are now in  associated FBs and tested. 

Our good friend blinky is deleted.

Means you have to guess when you can start the eth_serial communication, but even with blinky it was possible to start it too soon.

Using the include define flag didn't work because of the order of compiling.

But handcoding one so if no Button FB , buttons are not polled, which make Button FB not always required 

saves 2536  bytes.  We have enough space at moment, but that's alot isn't?

*2. Should all FBs that don't do port checking (L_LED, L_TOUCH, L_SOUND) be:

- deleted

- go in different pallette

- be kept and go in the same pallette

???

They are slightly smaller since not composite FBs, but would not be considered safe. 

3. Can LMS device wide constants go in LMS_DEV? 

 like max motors and max sensors?  in multiple places at the moment and shouldn't be.

supported sensor list?

After avr ctl is cleaned up, do its methods really belong in the LMS device?

Its not a sub-device, its part of the LMS device.

4. Comments and clean-up 

tabs - have to set for every type editor!!! Hope I got them all.

Made more things private in various classes

Either deleted extra comments or added a TODO or TOFIX to explain why didnt want to lose the info.

Added a few more checks for the motor including extra FBs for port checking

LC_M_PWR with port checking and  L_M_PORT FB 

Sept.27 All (updated) LMS FBs

Here are all the tested LMS FBs with updates:

Sept.27 Button FB and Motor FB updates

Button FB
LMS has little space so to save string space, event names are repeated 
BUT for the button I can never remember which is a "match" a button and "button changed", so changed to: 

• MATCH/CNF - button, b, pressed matches button pressed
• CHG/IND - button pressed changed (including no button to some button pressed)

Full Tests:

Use a e_cycle every 300ms to check the buttons

Test 1 (works, but..): 

Press button and associated led comes on

Test 2 (works, but..)

- Additonally when Enter pressed, then led comes on and motor moves.

- BUT sometimes when Enter released, led and motor stay on

- 9/29 Buttons are sampled at slower rate than thought so debounce time /counter was too long(1.5sec)/ large (25).   Changed so now works.

Motor FB

• Should a STOP event be added or is it ok to use INIT event to stop a motor?
• Removed BR, brake/coast, flag for L_M_PWR FB.
• Currently the motor is turned on and left on until stopped via INIT event or PWR =0.
• Braking when the motor power > 0, could be damaging to the motors.
• BR flag could be used in a future FB that moves a specific angle

Sept.26 Button FB works

Button FB works
Simple test:

Sept.15 -O2 and Button FB v1

(RIE 2011 is also today)


-O2 tests:

• smaller than -O3
• known as eCos device
• application deployment appears ok
• Simple app that just turns LED on works.

Button FB v1

INIT /INITO initialzed variables.
REQ/CNF 

• Q=true if the button # is equal to the button pushed
• RD - raw value
• BO - button #

IND/RSP will send true if button changed.


Button #s:

• 0 nothing 
• 1 ENTER 
• 2 RIGHT
• 4 LEFT 
• 8 ESC 

Time to test (and conference dinner)

Sept.14 -O3 optimization

-Os result - doesn't work

not recognized as an eCos device

-O3 results

• no  - boot blinky - 
• What does the boot blinky not working affect?
• yes -known as ecos device
• yes -deployment / running lego arm test application correctly
• the up/down works better... it doesn't drift down!!!
• 158592 (size)

(next task: Button FB)

Sept.11-12 Lego Arm application working

Following application does a simple test of the Lego arm

• turning left / right
• up/down  (drifts down - because of weight of motor(?))s
• open/ close

Sept.9 Application Time - Robot Arm

Chose 3 robots, which use few parts, to build and use with test applications,
First Lego arm to test motor FB in applications and for something new and 
because the other 2, (a CarBot, NXTway) use motors.


New motor FB since easiest to change directions in an application via a boolean:

Test 1: Test each motor going back and forth.  Same test was used for all 3 motors.
First simple alternating test with Flip-Flop

Test 2:  Used 2 Touch sensors - 1 turned motor on and 1 reversed the motor direction (both had to be pressed at same time)

Test 3:  Should allow testing of all 3 motors in 1 test.


Lego Arm test reflections / results:
1. Discovered easiest to change motor direction with BOOL input variable, 
so new Motor FB. 
Open: How to switch between on/0/off = tri-state
This is a general problem. Ref: http://www.societyofrobots.com/member_tutorials/node/161

2. Then a good test for changing directions  is using a flip-flop.
Created a F_FLIP FB that is a flip-flop built with 2 delays and 1 SR. 

This design was chosen because it uses 2 rather than 3 types, since each 

downloaded FB type takes more or the limited space.


Using F_FLIP FB there are timing issues. Usually goes back and forth, but sometimes misses one and goes twice in the same direction. Solution is probably to use E_CYCLE even if it an extra FB Type has to be downloaded.


3. Physical results:

• Open/Close - 
• hit on bottom of the other claw
• needs short times and little power
• Up/Down 
• Down is noticably faster than Up due heavy motor on the end of the arm
• Flop-flop with 2 equal delay times allows it to wander down fast.
• Can hit on motor if goes to far over
• Left / Right - works as expected

Sept.8+ Optimizing for size

Using -Os to compile LMS drops the size from 24k to 17k.
But even boot blinky doesn't work...... more to come.

Sept.6 Testing Composite FBs

Composites are working: LC_AD, LC_TOUCH, LC_LED, LC_LT, LC_SOUND
eCos and Forte keep getting smaller.
More interesting was using 1 application, but various combinations of FBs. 
For example testing FBs in the composite network before testing the composite FB.
Another example shown below is the application that was used to test both LC_LT and LC_SOUND. Since both sensors are on port 1, both sensors cannot be mapped to the device during the same test.

Sept. 5 Smaller Forte and ecos

New smaller Forte and eCos packages, so back to 1 version to test.  0904cyg 
Can finish testing all new LMS FBs now...  (current size: edef4)


Test Cases

• Compiles, Links, Boot Blinky: -works
• 4 LED app -works
• FlipFlop app 1 -works
• FlipFlop app Cycle -works
• Touch LED on app  - LC_TOUCH not working
• Reads app - also not working.... backing off to test the FBs that make up the composites
• Motor on app  -works
• 3 Motors on app - uses TOUCH sensor to turn on

Sept. 4 LMS FB clean-up tests

Forte has grown as it has stabilized, not leaving much room in 256K for lms FBs 
LMS FBs C++ /  4diac 0.4 are cleaned up; Now using Composite FBs (see previous post)

Testing one after the other 3 base versions : 

• 0904cyg; With current forte with LMS NXT modification compiled into ecos package 
• BASE is TOO LARGE now. Only L_LED fits
• 0904:   With current forte (1.0)    
• The base forte has grown!
• 727z:      With 0727 forte
• all LMS HW functioned prior to using composite FBs

Tests: black works, grey not yet tested, orange fixing
 note: have to change apps to use most current FBs wtith sensor type.

• all compiles and link
• 727z, 0904, 0904cyg
• Boot Blinky:
• 727z, 0904, 0904cyg
• 4 LED app: (deploy works)
• 727z, 0904, 0904cyg

arm-elf-size forte.elf  size Info

1. with LMS NXT modification compiled into ecos package 

Linked fine,but its too large now, think it should be same size since it should have just changed locations, but

with all LMS FBs  size is 42d9c > 4000  = 256K (max) 

Only small enough with just LED FB : 3fd34

Both Boot Blinky and deploy of an application work.

[Could this be the large eCos version that caused similar space problems in Feb.?]

2. With current forte (1.0) = 0904 forte

when I changed to the most recent forte and it has grown!!!

3f8e8 !!!!  Max is 40000x =256K

3a214 is smallest with only the old Boot Blinky code and no AVR initialization

changing the queue parameters makes no difference to the size 

What caused it to grow so much? Anything else that can be left out?

3. With 0727 forte

0727 forte 3f69c with all LMS FBs in previous post.

Minor side notes:

1. Did some optimization and found the local variables sometimes make it smaller, but in the case of L_LED it was smaller using local variables.

2. Finishing up the lms code I tried to move all the port related code in the FB L_S_PORT, but had problems moving the static constant arrays that were initialized and private methods into the exported code. Not a priority, but if you understand this cryptic description and have hint I will try again... otherwise I will leave the code in a separate class.