Command delays in Logicator

[TerryRy]

I have found that some commands, for instance ReadTemp cause delays in the execution of commands in other starts whilst to data from the sensor is read (up to 750mS). In my case this causes sluggish or unread button presses in the real hardware. The program also misses Time compare functions which have a 1 second window. I suspect that other I/O serial functions will have problems the way I have written the flowsheet.

Can anyone tell me which commands (ie. LCD, Wait, InfraIn, InfraOut) cause delay problems and what the delay may be for subsequent commands in the same start and others that are running in parallel? Are there ways to minimise these issues in Logicator and still have a responsive user interface?

Thank you

 

[hippy]

Though the PICAXE M2 are multi-tasking they can actually only do one thing at once. What they do is interleave the tasks used to give an impression of simultaneous execution. When a blocking command ( such as READTEMP ) is encountered all tasks will block until the input is available, and READTEMP can take up to 750ms to determine a temperature.

Blocking commands are all input commands such as COUNT, INFRAIN, KEYIN, PULSIN, READTEMP, SERIN, SERRXD. Also output commands such as PULSOUT, PWM, SEROUT, SERTXD will block for as long as they take to do what they need to.

The only ways to improve program response times with a DS18B20 temperature sensors is to use a PICAXE X2 and OWIN and OWOUT commands to read the temperature ( but multi-tasking will not be available ), or to add an additional PICAXE which can read the temperature and tell the main PICAXE when there is data available for it to read and provide that data when it is requested. The temperature reading PICAXE can then block without causing the master program to wait.

 

[TerryRy]

Thank you for your answer. Now that I have a better understanding of the limitation of the interleaving of tasks I can structure my flowchart to minimise the use of these blocking tasks. ie. refresh the data less frequently and only write to the LCD when data has actually changed (although I will still have to perform a few ReadTemps to find out if the value has changed!). I will also find a way to widen timing windows. Trapping button presses seems a lot more difficult to secure or does INTERRUPT achieve this even during blocking tasks?.

I could also run the PICAXE at a higher speed, use higher baud rate for serial devices but this would be a bit of a challenge for me at this stage of my learning curve as I would like to stick to Logicator as a development tool.

I would imagine ReadADC would also take some time. Do the SOUND and WAIT commands also block? Is there a table somewhere of the number of clock cycles typical for each command (understanding that serial ones will be dependent on the data length)?

Perhaps someone could come up with a simple program where a command with parameters could be inserted and delay caused by the command measured and displayed.

cheers

 

[hippy]

WAIT and PAUSE won't block and READADC takes no more time than any other commands. I can't recall off-hand if SOUND blocks but I think it does - should be easy enough to test.

Unfortunately interrupts won't be responded to while a command is blocking.

As to a list of how long a command blocks that's really however long it takes to receive or output data.

When running multi-tasked the M2's are locked to 16MHz operation and that cannot be changed. READTEMP will however still take up to 750ms ( it's the DS18B20 which takes a long time from being asked for its data to delivering it ) so you wouldn't gain anything if you could.

 

[TerryRy]

Thanks Hippy. I have gone back and read the instructions (manual) again and found that a lot is explained in Getting Started from page 59. There is lot of information there which is now beginning to sink in. Anything that is not specified I can find out by trial and error now I understand the basics of the slightly misnamed multi-tasking.

WHEN ALL ELSE FAILS READ THE INSTRUCTIONS!