About 3 minutes. We build it, run it on real INtime nodes and send you the result.
10%
Let's start
Connect
Describe
Your details
We build
Request received!
1We build it – our skilled team turns your words into a working solution
2We verify it – running on real INtime nodes, in a real-time environment
3You get it – one ZIP by e-mail: the solution and a recording of it running
One more step: your . Put , unchanged, in the Google Drive folder we share with you. If you do not have its link yet, it comes by e-mail. We start building when every file is there.
No INtime licence yet?
Register for the evaluation software – one month, free.
Thank you – the registration page has opened in a new tab, and we have been told that you asked.
How it works
You describe your real-time application, in your own words.
We build it as a Visual Studio solution.
We run it for two minutes on real INtime nodes, against a simulated device, and measure it.
You get one ZIP by e-mail: the solution for Visual Studio 2019 and 2022, and the recording of the screens.
Do I need INtime?
No – to try it, watch the recording.
With INtime and Visual Studio, build and run the solution yourself.
Who are we?
A team of experts combining dozens of years of real-time experience with AI and platform engineering to make real-time solutions easy – leaving only the deadlines hard.
Our work-horse is on it – on time, every time, down to the microsecond.
What your software connects to
A UEI card – preferred when your I/O is one of the UEI cards we simulate: digital or analog lines, counters and encoders, serial, CAN. Moving from our simulator to your real card is almost transparent – the same program, one start-up argument changes.
Ethernet – your own protocol over UDP or TCP, or a standard one. Tell us its details: the messages, who sends what and when, UDP or TCP, the ports – or the standard's name and version.
Shared memory – the device and your software share a memory section. What we need is how data moves to and from the device, and how each side signals it is ready – no interrupt, no polling.
No I/O, or another interface – your software runs on its own schedule and connects to no device; or it talks to a device through an interface other than these three – describe it in part B, and we can often build a simulator for it.
Who plays the device?
A simulator stands where your device would stand.
For a UEI card: the card and whatever is wired to it.
For Ethernet: same wire, same address, same port.
For shared memory: a simulator on Node B, sharing the memory with your software on Node A.
For another interface: a simulator built from what you write in part B, where one can be built.
Choose one of the four. Moving from the simulator to your real device is almost immediate for a UEI card or Ethernet; for a device sharing memory it needs some adaptation, because a real device brings its own memory map, doorbell and interrupt – the more of its interface you describe, the less there is to adapt.
The card families
Tick every family your software uses. For each one, here is what our simulator carries:
What to write
Your own words. Cover what you can:
A – Your software
How often – e.g. every 10 ms
What it sends or reads, and how much – e.g. 64 bytes
What counts as success
What Windows shows, so you can see it worked
B – The device
Which UEI boards or layers, and which channels
Its protocol – the messages, who sends what and when, UDP or TCP, the ports – or the standard's name and version
The transfer and the signalling – what each side writes and reads, and how each side signals it is ready; the device's memory map, if you have it
What it answers, when, and with what values
What it does on its own – does it send first, or only answer? That decides who starts the traffic.
Optional – left empty, the simulator uses sensible defaults.
B – Another interface
Only if your software talks to a device through an interface other than a UEI card, Ethernet or shared memory.
The device and the interface it uses – the messages, the timing, who starts.
Optional – left empty, your software has no I/O and runs on its own schedule.
Good to know
Everything we build comes out of what you write here.
What you write outranks our defaults.
We only ask about what you did not say – What we need, under the boxes, shows what that is.
The ready example is a run we already built and filmed – send it as is, change it, or write your own.
The device – what we simulate
A simulator on Node B stands where your device would stand, and behaves the way you write here.
Which UEI boards or layers, and which channels – e.g. DIO-403, lines 0–7 in, 8–15 out – and what the device on them does. See the UEI cards we simulate.
Its protocol. Your own over UDP or TCP: the messages, who sends what and when, UDP or TCP, the ports. A standard one: its name and version. Left out, the simulator speaks a simple protocol of our choosing.
The transfer and the signalling – what each side writes and reads, how big, how often, and how each side tells the other that data is ready. Have the device's memory map? Add it as a file here; without it we use our own.
Who starts the traffic is the answer that turns a whole solution around. Say it plainly: The device sends a status frame every 20 ms on its own – or The device only answers; it never sends first.
Write sentences about the device – The device answers…, The device sends… – so we read it right.
Optional. Left empty, the simulator uses sensible defaults.
Files here – its manual, register map, message list – describe the device. Files about your own software go in part A.
Another interface – what we can simulate
Only if your software talks to a device through an interface other than a UEI card, Ethernet or shared memory – for example the PC's own serial port, or a board with its own registers.
Describe the device and the interface it uses: the messages, the timing, and who starts – does the device send on its own, or only answer?
Write sentences about the device – The device sends…, The device answers… – so we read it right.
We can often build a simulator for it; what comes back to you says whether we did.
Leave it empty if your software has no I/O – it then runs on its own schedule.
Files here – the interface's manual, its message list – describe that device. Files about your own software go in part A.
Why we ask
Your description did not say this – one number and we are done.
Your details
E-mail – where your recording and your package are sent.
Phone – so a question takes two minutes, not two days.
Used for this request only – no mailing list.
Remembered in this browser for your next request.
Before you send
We will build – what you said and what you chose.
We will assume – what we use where you said nothing. These are ours, and the ones worth arguing with.
Change takes you back to where it came from. Nothing is lost on the way.
It goes out in your name. A note you add goes with it, in your own words.
What we need
The facts that decide what we build, read from your words as you type.
Each line says where its value came from: read from your words, you chose, we will assume or missing.
Wrong or missing? Click the line and choose. Your text is never changed – your choice sits beside it and wins.
If your words later say otherwise, the line shows it, so you can make them agree.
Only who starts the traffic must be settled before you continue: it decides which end we build as the simulator.
Some lines can only come from your words – the line says so.
Files that define it
Optional. Your description is enough to start; files make it right the first time.
What helps most: the device's interface – its registers or memory map, its messages and timing – and source code that already talks to it on another system.
For each file, say what it is and which pages or parts matter.
Add each file in the part it describes – your software or the device. The limits are for both parts together.
Why some files are refused
Programs and compiled code (.exe, .dll, .lib, .obj, firmware images) – we read source, never compiled code, and we never run anything you send.
Formats we cannot open – help files (.chm), old Word and Excel, presentations, Visio, CAD. Each refusal says what to save it as instead.
Too much – a request is one application, not a library. Past ~100 pages, the risk is that we take a value from the wrong chapter.
How we use them
What you write in the description wins over a file, and your solution lists every fact we took from your files, with the page.
Your files are used for your request only, never shown to anyone else, and never kept with other customers' work.
How to make a file lighter
What we use is the text and the drawings that matter. Most of a big file's size is pictures and pages we do not need.
Send only the chapters that matter. Open the PDF, choose Print, pick the printer Microsoft Print to PDF (or Save as PDF on a Mac), type the pages – e.g. 12-30 – and save. A 400-page manual usually becomes a few MB.
A scanned PDF (pages that are photos) holds no text we can search. Ask the vendor for the digital PDF, or use your PDF reader's Recognize text (OCR) and save it again.
Word with many pictures:File → Save As → PDF, and in the options choose Minimum size. Or remove pictures that do not explain the interface.
Excel register maps or tables: keep the sheets that matter, or save each as CSV – pure text, a fraction of the size.
Help files (.chm): open the topics you need and print them to PDF as above.
Source code: zip the source only – leave out bin, obj, .git, build output and libraries.
Pictures: a screenshot of the timing diagram, cropped to it, as PNG – not a photo of the whole screen.
Then say in the file's note which pages or parts matter. That is what we read in full; the rest we only search.
